Re: [gnome-network]GTransferManager Architecture

[Manuel Clos <llanero eresmas net>]

Rodney Dawes wrote:
> Are my mails particularly hard to read or something? I answered most, if
> not all of the questions you asked here, in the mail which you are
> replying to.

Sorry Rodney. I'm not a native english speaker. When I'm repeating 
questions is because you haven't answered them or because I didn't got 
your point. So I politely ask you to try to explain better or in other 
words.

> Il sab, 2003-09-27 alle 20:09, Manuel Clos ha scritto:
>
> > Rodney Dawes wrote:
> >
> > > What is the difference between the two? Any local config/data file
> > > access is going to have to be locked. The best way to do this, is
> > > to have only one thing accessing the files we need. It's also very
> > > easy to just use the machine information as part of the filename to
> > > avoid conflicts from multiple machines accessing an nfs/etc... mounted
> > > home directory, also.
> >
> > Well, in the first case you are sharing the whole machine, so a single 
> > daemon makes sense. In the second case you are only sharing the home dir.
> >
> > What I don't know is what happens when you log from different machines. 
> > Do you see the same desktop? Do you see the same files? Then, you should 
> > alse see the same list of transfers.
> No. You don't see the same desktop really. Namely because GNOME doesn't
> really handle shared home directories very well. Everything is not the
> same.

In the above text, you first say "Any local config/data file access is 
going to have to be locked.", but then talk about "use the machine 
information as part of the filename to avoid conflicts". So at this 
point, what solution are you proposing?

I know we already agree on just having one daemon in the two displays - 
one machine case. But in the two machines - one home dir case, my point 
is that if you see the same desktop (desktop files, ...) you should also 
see the same list of transfers. If this is not what should happen, i.e. 
you should see a different desktop, then it must be done gnome wide and 
not per app.

If I understanded it well you are proposing two daemons in the second 
case. I was asking you what of the two methods you proposed (locking, 
using different filenames) was the one you wanted to implement.

Hope I now explained my idea better.

> > Two daemons accessing the same files is a problem. What are you thinking 
> > as a solution?
>
> As I said, don't use the same file for multiple machines with shared
> home directories. Instead, encode the machine name as part of the
> filename.

This should be solved by the above explanation: if you are going to see 
different desktops from different machines it should be done gnome wide.

> > > No. It should pop up on the display where the transfer was initiated.
> > > The amount of time between when the user asks for a transfer to occur,
> > > and the dialog gets popped up to ask for a password or anything (if it
> > > does, ever), is going to be minimal.
> >
> > Not always. You seem to not take into account "queued" transfers, 
> > "scheduled" transfers, or just "finished" transfers that are showed in a 
> > dock in the system tray. Showing the dialog in both displays, and then 
> > hiding both when the user answers one on them would be better, don't you 
> > think so?
>
> Queued/Scheduled, or completed transfers are no different from any other
> transfer, other than their status is not constantly changing. No,

Ok, I will try to explain better. I was refering to the _password_ 
dialogs and other input requests.

In the multiple-machine case, if you are going to see different 
desktops, then there is no problem. I was proposing to pop up the dialog 
in different machines _if_ the user is going to see the same desktop. 
But we agree that it is better to see different desktops.

In the single-machine case, I asked you:

"Also, how do you see it working? I think that in the first case the 
user should see the same list of downloads, ..."

But you didn't answered. If the user is in the same machine logged as 
the same user, and there is just one daemon, he should see the same list 
of downloads, these means that poping dialogs in both displays (and then 
hidding) makes sense. And it makes sense because it is different from a 
file manager. Usually you will do transfers in various _sessions_ so you 
want the same list. You can do transfers in various sessions because of 
a big file or because of lots of files.

What is you point here?

> transfers that are not in-progress should not show an icon in the system
> tray. And what's with the fetish of throwing crap in the system tray? If
> there are 300 files in the list of transfers, and they are all
> completed, why should one care that they are still there, so much as to
> have an icon sitting in the tray, doing nothing, other than wasting
> space?

No, this is not what I said. I said: "... or just "finished" transfers 
that are showed in a dock in the system tray...". This is just another 
way of user interaction: telling the user a download has finished. This 
means poping a sticky-note like dialog next to the dock in the system 
tray, just that.

> > > The cases of multiple login are indifferent to me. We need to handle
> > > them all. If the logins are on different machines, clearly there are
> > > going to be different daemons running.
> >
> > If you are in the same machine, there is no need of the overhead of 
> > running two daemons.
>
> Did you read what I said? This is the entire purpose of the "middle-man"
> client/daemon. You need to handle all displays.

This also has to do with my answer about your point of seeing / not 
seeing the _same_ list of downloads on different displays.

> > How do you see the two daemons coordinating the work?
> See above and previous mails where I explained this already.

You explained two solutions for coordinating different-machines logins, 
which as I said should be done at gnome wide level. And anyway, you 
proposed two solutions, I was asking specifically which one.

> > > It means the window with a GtkTreeView that shows you the list of
> > > downloads. Or it means the web browser where you ask it to download
> > > a file.
> >
> > I don't see the reasons to do so. What differences are between 
> > connecting to the daemon versus connecting to the manager?
>
> Huh?

I see the display manager showing the dialogs requesting passwords, 
dialogs about overwrite, and providing a progress window. In this 
scenario I see the clients connecting to the daemon. Since I'm seeing it 
from the point of having just one list of transfers.

It seems that you want to have different lists of transfer for each 
display, then it will make sense for clients to connect to the display 
manager instead of the daemon. I just think this is not the better 
solution and was asking you arguments about your point, examples, and so on.

> > > So we can more easily maintain a consistent interface for progress
> > > dialogs, authentication dialogs, and other aspects of the UI, and not
> > > require all the clients to do a bunch of extra bonobo stuff to know
> > > that a password is being requested, or the download is 80% complete.
> >
> > When a password is requested, it should be managed by the display 
> > manager, not the clients. This is why I don't see you point about why is 
> > better to do communication _trough_ the manager. I think that starting 
> > an epiphany plugin will show what the real issues are, so perhaps you 
> > are right.
>
> Uhm. It is displayed by the only client the real back-end has, the
> middle-man client. I have no idea what you are complaining about
> right here, other than the fact that it seems like you didn't actually
> read what I said previously.

I explained my question better in the above paragraph, sorry.

> > I've got some time this weekend, so I will be able to start moving 
> > downman over to gnome-vfs.
> *sigh*

??

Hope I explained better :)

See you!

--
Manuel Clos
llanero eresmas net
http://llanero.eresmas.net