Re: [gnome-network]GTransferManager Architecture

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]