Re: [gnome-network]GTransferManager Architecture

[Manuel Clos <llanero eresmas net>]

Rodney Dawes wrote:
> 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

Ok.

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

People is working to make multiple logins in the same machine work. I 
think we can leave the second case alone.

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

Ok.

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

So same user, same machine, different displays, same list of downloads.

I meant by session the time the user is doing transfers, then switches 
off internet/computer. Some files will need various sessions to 
transfer. This is the primary reason to always see the same list of 
transfers.

> 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

> 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

After discussing the various issues and cases it won't take into account 
it looks fine.

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

>             +--> DISPLAY=:1.0 manager <--> DISPLAY=:1.0 front-end
                       ^^^^^^^^^^^^^^^^^^^^^^
Sorry I was not clear enough. I just joined that two words meaning "the 
manager for that display"

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

Umh, I supose you mean "handling I/O between the back-end and the app 
and providing user interaction".

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

No, I was not proposing each app to do their own UI.

My idea is clients connecting to the daemon throught the middle-man, but 
the middle-man not managing I/O between daemon and clients but just 
managing UI stuff like password dialogs and such. So you efectively know 
where you should pop up dialogs.

                              Password dialogs, progress windows, ....
                                           +
                                           +
daemon ------------------- middle man ------- connecting + commands 
--------- clients (epiphany, transfer manager, dock, basket, ...)
      + 
                                                  +
      +---------------------------------- getting status data 
--------------------------------+


one daemon, one middle man per display (as you propose). (we do not care 
about different machine logins)

Status data is by far the operation that takes more data, there is no 
need for the middle man to proxy that, it just adds overhead.

What do you think?


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