Re: [gnome-network]GTransferManager Architecture

[Manuel Clos <llanero eresmas net>]

Rodney Dawes wrote:
> Il ven, 2003-09-26 alle 08:06, Manuel Clos ha scritto:
> > Is the user logged into the same machine from different displays? (a)
> > or is the user logged from different machines but sharing the home dir 
> > via NFS? (b)
> >
> > What case are you refering to?
>
> 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.

Two daemons accessing the same files is a problem. What are you thinking 
as a solution?

> > Also, the middleman should ask for interaction in all the displays, 
> > don't you think so? This way the user can type the password (...) don't 
> > matters the display he is using at the moment.
>
> 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?

> > > What do people think about this?
> > >
> > >            +--> DISPLAY=:0.0 manager <--> DISPLAY=:0.0 front-end
> > > back-end <--+
> > >            +--> DISPLAY=:1.0 manager <--> DISPLAY=:1.0 front-end
>
> 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.

How do you see the two daemons coordinating the work?

> > I don't understand what front-end means here? does it mean other 
> > clients? or the GUI for the manager?
>
> 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?

> > I think other clients should talk to the daemon directly (trough the 
> > lib, of course). Do you think of any reason they shouldn't do it 
> > directly and do the communication through the manager?
>
> 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.

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

See you.

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