Re: [gnome-network]GTransferManager Architecture

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.

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

> 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

> > 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,
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

> > 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.

> How do you see the two daemons coordinating the work?

See above and previous mails where I explained this already.

> > 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?


> > 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've got some time this weekend, so I will be able to start moving 
> downman over to gnome-vfs.


-- dobey

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