Re: [gnome-network]GNetworkTransferManager

[Manuel Clos <llanero eresmas net>]

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

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


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