Re: [gnome-network]downman description

[Rodney Dawes <dobey free fr>]

Il lun, 2003-09-22 alle 12:05, Rodrigo Moya ha scritto:
> On Mon, 2003-09-22 at 14:59, Manuel Clos wrote:
> > downman is modeled after the idea of having a separate proces, a daemon, 
> > that takes care of downloading / uploading files. I found this idea 
> > first in darxite and then implemented it in downman. It is much like 
> > Rodney said: "... I have been planning on rewriting it from scratch to 
> > use a separate daemon backend and gui frontend code ..." when refering 
> > to emphetamine.
> > 
> yes, that's the general idea, but after looking at the daemon code in
> downman, I just wonder what we can reuse there, if anything at all. It
> doesnt use gnome-vfs, it relies on opening FTP/HTTP sockets. It should
> use the async interface in gnome-vfs instead of using threads, and I
> cant see the way your current code can be changed to that without being
> re-implemented.

Yeah and I guess by "rewrite from scratch", I mostly meant "rearchitect
a little bit and clean up the code". I'm already using gnome-vfs and
it's async interface, and it's a pain to use, let alone get it right.
I'm also already using bonobo and basically have a complete IDL for at
least starting a download.

> >  Like many other download managers, 
> > downman can manage different lists of downloads. This lists are called 
> > Projects. When you first start downman you only have one project. In 
> > Gnome Download Manager you can see this because it will show you no 
> > tabs, this is, it will look like a simple list.
> >
> this sounds like a good idea

I don't like this idea, actually. It makes for a very complicated UI,
and then you will need a complicated API to support it. "I have to
create a /project/ to download a file?"

> > At this point you have the basic functionality
> > 
> > clients <------------------------> daemon <------------------------> 
> > projects <------------------> downloads / uploads
> > 
> > To make it easier, there is a util library that implements the commands 
> > as a C API, so you have:
> > 
> > gint        dm_client_local_connect (gchar *name);
> >
> what does local_connect mean? That you can connect to remote download
> managers also (ie, is there a remote_connect call)?

As emphetamine stands, it has absolutely no need to be able to do
something like this where you would connect to either a local or remote
backend. You simply just do the necessary stuff, and with the file
chooser that it's using from libelysiumui, you can just browse to other
machines, and use ssh, ftp, http, smb, or some similar method to just
save the file to the other machine, rather than your own. I've tested
it quite a bit by downloading most of ftp.gnu.org this way, and it
worked great. The only problems came when gnome-vfs would trip over it's
own feet.

> > gboolean    dm_client_daemon_start (GError **error);
> > 
> this is not needed at all in the Bonobo-based case, since the daemon
> will be started when activating it, it it's not been started before.

Right. We will need to handle multiple display cases though, so that
we can have per-display daemons, so that everything works happily.

> > There is also a floating window (downman-gmonitor) where you can drop urls.
> > 
> that might be a good idea also, although I guess it is much better to
> have the daemon display an icon in the system tray, and make it accept
> dropped URIs.

Currently emphetamine does this by default, but it doesn't seem like the
best thing to have. Ideally we want to just have everything work with
it, so that when you click a URL in epiphany or whatever, it just uses
the manager we have in g-n. The main UI window will still accept drops,
and the status icon can, while it's displayed, but I'd rather have the
status icon be more or less shown only while something is being
transferred. This will help lower the probability that the notification
area will get cluttered by things shoving persistent icons in it, and it
will still be useful while something is happening. Emphetamine is
designed in such a way that it can do this, display the progress in the
main window's list, or in a dialog similar to IE, provided I were to
write the code for the dialog.

> > As every download manager, downman saves the list of downloads, it does 
> > so in using libxml. And the same is true for downman and projects 
> > configuration.

Emphetamine doesn't do this currently, but it has been planned for some
time. I just have not had much time to do work on emphetamine and finish
getting it ported to gnome2 and adding such features.

> > Next in my TODO list is:
> > 	- Moving to use gnome-vfs everywhere
> >
> this will mean rewriting most things in the daemon, which is similar
> than starting from scratch, which is what Rodney is planning.

I'm not exactly planning on starting from scratch. I'm shuffling code
around, cleaning it up, and splitting some things up.

> I must say, to not sound so harsh to you, that the UI of gdownman is
> nice, and if nobody has a better UI idea, we might end up reusing a lot
> of your UI.

The UI is the trivial part, and most if not all download managers, have
roughly the same UI.

-- dobey