Re: [gnome-network]GTransferManager Architecture

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

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

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

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?


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.


Hope I explained better :)

See you!

Manuel Clos
llanero eresmas net

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