Re: [gnome-network]GTransferManager Architecture

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


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.


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

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