Re: [gnome-network]GTransferManager Architecture

[Rodney Dawes <dobey free fr>]

Il dom, 2003-09-28 alle 11:12, Manuel Clos ha scritto:
> 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?

Why not both? It is probably best to do both. It is easiest to construct
a filename with the host name of the machine included in it. So, I will
probably be doing that only at first. I have no intentions of trying to
deal with locking issues on all the various file systems that may end up
having your home directory on it.

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

What you don't seem to understand is that GNOME doesn't exactly handle
either case. If you want to fix all of GNOME to support multiple display
logins and nfs-mounted home directories properly, feel free. I am sure
most people will accept patches for that.

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

I'm not proposing it. I'm stating that that is how it is. You can of
course, make this not be the case, by changing your configuration to
activate remote objects, in which case, you can use the daemon that
would already be running on a host machine.

> Hope I now explained my idea better.

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

It all depends on what "desktop" is. And, I'm not even going into that
whole crack-addled flame war. The simple fact is that GNOME does NOT
handle either of the above scenarios properly, and I'm not going to fix
it so that you will be happy with whatever I am writing for the transfer
manager for gnome-network.

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

Password/etc... dialogs will appear where they are initiated from. It's
that simple.

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

I don't agree with what is better about what the user sees when they
log into some arbitrary machine on their network, while they are already
logged in to some similar arbitrary machine.

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

I did answer. Rather clearly, I thought. The list of downloads that the
user sees in the window, is dependent on who they are logged in as, and
what machine they are on. I don't understand what you mean by "sessions"
here, but whatever. To me a "session" is the lifetime of the currently
running process.

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

Telling the user that a transfer that they just initiated is one thing.
The user will receive notification of when a transfer has completed, of
course. That is a given. I have absolutely no idea what else you are
talking about here. It seems like you keep writing very long sentences,
and then when I say something that is counter-intuitive to what you
meant, because I didn't really understand what you said, you end up
splitting up the paragraphs/sentences and say "no no, *this* is what I
said."

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

No it doesn't. At least, it doesn't have any sufficient amount of
relativity to that. Just ignore the nfs home directory situation
for now. I don't care about it for the time being. GNOME doesn't
work properly with it. It's probably not going to for a while. And,
when it does, we will probably get that support automatically. GNOME
doesn't handle multiple-display logins properly either, but I am not
concerned with GNOME working it's best either, with this. I am asking
for constructive feedback on what I laid out as the architecture for
GTransferManager in gnome-network. That is *all* I care about for the
time being, and in the context of this mailing list. I could come up
with many more situations where we would have problems, if you really
wanted me to. I just don't care about those. It's not worth the time.

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

If there are multiple daemons, they aren't coordinating the work. Unless
you are talking about the middle-man client/daemon. I honestly have no
idea what you are trying to say here.

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

What "display manager"? GDM? What are you talking about here?

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

No. Machine. Read what I wrote. *sigh* Really. Are you referencing the
"middle-man" client/daemon as "display manager"? It's not managing
displays, it is handling I/O between the back-end and the user for very
specifically defined tasks.

If you want clients to all do their own UI, then you don't belong here.
This all *must* be consistent and integrated. We can't have 30 different
dialogs for the same thing. That is ridiculous. You've not given any
better solution, or provided any data to prove your point. I've thought
about this long, and hard, and what I mailed to the list seems to be
the best solution.

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

I don't think so. :(

> Hope I explained better :)

It will be easier to understand what you are talking about, if you don't
take what is said in the mail you are replying to, and make up your own
words to describe what you think it might be doing. "Display manager" is
a term for gdm/xdm/kdm/etc... where it is actually managing displays.

-- dobey