Re: [gnome-network]GNetworkTransferManager

Rodrigo Moya wrote:
This is internal to the libgnetwork class we talked about. Apps should
not have to talk CORBA directly to access the daemon. Just use the
libgnetwork provided interfaces.

Sorry, perhaps I didn't explain very well.

Apps will talk CORBA to the bonobo client. This is, an app calls TransferManager :: newDownload (url) and then the bonobo client pops up and does the job. Of course, yo can do it with a C API. Then you will have gnome_transfer_manager_download_new (url). It seems that you are proposing just what utillib is, but perhaps a bit more abstracted.

For the bonobo app it will work like:

Daemon <---- comunication ----> bonobo <---------- comunication -----------> aplications

(the bonobo client uses utillib, so that it is easy to connect to the daemon and send commands)

And for apps using utillib (libgnomenetwork) directly:

Daemon <------ comunication using utillib ----------->  applications

The idea of having the bonobo client was to avoid apps to depend on utillib/downman. Of course, if it is in libgnomenetwork then it is ok for apps to depend on it and a C API will probably be better.

The bonobo client is still todo, so if you think of using downman it is probably better to use a C API for apps.

You should start thinking how much api is going into libgnomenetwork (download manager, desktop sharing, ... ), because it will be huge at the end. What is the current plan for APIs in libgnomenetwork?

module GNOME {

    interface DownloadManager : Bonobo::Unknown {

        void newDownload (string url);

hmm, that seems like too little. how would you tell the daemon to
start/stop a download?

Yes, this is just an example. In downman-utillib there are commands to get an url, start, stop, delete and everything you will need for a client. So it seems that you are proposing apps using libgnomenetwork wanting to download an url to be clients to the daemon directly.

Something like:

gnome_network_download_new ()
gnome_network_download_url_set ()
gnome_network_download_start ()

which is what downman_utillib provides so that it is easy to build/abstrac clients for/from the daemon.

Of course, this bonobo client also shows a GUI so that the user can control the properties of the download/upload. Then the interface also needs _events_ so that the program requesting the download/upload is notified when it is finished.

so, your component implements everything? Apps just activate it and
leave its UI do its job?

If so, I dont like this plan, sorry :-) The daemon should just not have
any UI at all. And it should contain methods for giving it orders (start
a download, resume it, pause it, etc).

No, this was the example of the bonobo client, so that apps don't depend on the transfer manager, but as I said if it is going into libgnomenetwork then there is no problem for apps to depend on the client library directly.

The idea of providing an UI is that the user always gets the same UI when doing downloads/uploads no matter what apps they are using, think of it like a GtkFileChooser but for downloading / uploading files.

could you please send a detailed mail of the downman architecture? I
should have looked at the code, but days only have 24 hours :-) So,
please do it, so that we all know what we're talking about.

Ok, I will do so.

Has it been considered for inclusion?
yes, it is being. Although, based on what you say, it seems it's got a
lot of problems. I'll shut up though until you send your mail about its

What do you mean by lot of problems? can you enumerate them?

Manuel Clos
llanero eresmas net

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