[gnome-network]downman description

[Manuel Clos <llanero eresmas net>]

Hi all,

I'll try to do some downman marketing :)

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.

The daemon is per user, like gcond. It must be started when the first 
application needs it (nowadays Gnome Download Manager).

The daemon consists on a simple thread where a GMainLoop waits for 
events. These events can be clients trying to connect, clients sending 
commands or downloads changing state. 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. The Project GObject 
takes care of the downloads. Every seconds it runs the scheduler to see 
if there are any queued download and starts it if possible. Here is also 
where the speed limits are calculated.

Then, there is the Download class. Every download has some properties 
like url, destination dir, speed limit, current downloaded bytes, status 
of the download, ... Every download runs on its own thread. When running 
it goes in a loop to read and write data and checking for events until 
it finishes.

When a download finishes, changes its status or something happens, a 
g_signal is emitted so that the Project knows what has happened. The 
project then emits a signal so that Downman (the daemon class) can 
notify the clients that have requested to be sent events.

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);
gboolean    dm_client_daemon_start (GError **error);

which allow clients to connect and to start the daemon.

GString *   dm_command_get_new          (guint project, const gchar *url);
gint    dm_command_get                  (GString *item, guint fd);

this is the minimun command, you can also set other properties like 
localpath, speed, ...

The utility lib also has the common commands:

gint    dm_command_download_start   (gint fd, guint project, guint 
download);
gint    dm_command_download_stop    (gint fd, guint project, guint 
download);
gint    dm_command_download_queue   (gint fd, guint project, guint 
download);
gint    dm_command_download_delete  (gint fd, guint project, guint 
download);


At this point, creating clients is just a matter of calling the 
local_connect function and adding a download.

Clients in downman are classified under the clients tree, where you can 
have CLI clients (downman) or GUI clients (Gnome Download Manager)

Gnome Download Manager uses all the features that are implemented. It 
connects to the daemon and shows the list of downloads, where you will 
see no tabs when there is only a project, and a GtkNotebook when there 
are more than one project. You will have the list of downloads along 
with the status, % done, .... The GUI does not block because it uses 
events in the file descriptor to read the info coming from the daemon. 
It allows you to add downloads, start, stop, delete, ... and set the 
properties of the donwloads (even speedlimit in real time). I have 
always followed the HIG when doing the GUI. It uses glade for easy 
modification.

So as Gnome Download Manager only uses the util lib, moving the daemon 
and util lib to gnome-network will mean that it only needs to link 
against libgnomenetwork. Of course, moving the GUI will be great too.

There is also a floating window (downman-gmonitor) where you can drop urls.

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.

There is now a Servers feature, where all servers that have a maximum 
number of connections get saved to the servers.xml file. Of course, this 
can be expanded to include more server properties.

I have been always writing downman for integration with gnome2, so I 
used glib as the base for the daemon and utillib. Followed the HIG when 
creating GUIs. Using libxml for the files. GIOChannel for reading and 
writing. GThread. GString and so on.

It much provides what rodrigo wants:
	* basic functionality in libgnetwork   --> this is util lib + the daemon
	* try to push that library to be used in other apps   --> a better util 
lib API and/or a bonobo Interface
	* have a nice GUI   --> Gnome Download Manager

Plus other itheas like:
	- daemon / GUI separation

Next in my TODO list is:
	- Moving to use gnome-vfs everywhere
	- Renaming / restructuration of the code if it is being moved to 
gnome-network

I really want to help gnome-network to get a good _transfer_ manager. 
And I think downman is a good starting point. I invite to Tapia and 
Rodney to take a look at downman and help with the move to gnome-network.

Downman has been working for some time and is pretty stable.

I have also looked at Tapia code, but it is pretty simple and puts 
together the download and daemon information. There is need for a 
separate download / upload / transfer class and leave the daemon to do 
only the scheduling, client management, saving configuration and list of 
files, much like downman does now.

So now I'm waiting on people telling what are the problems for going in. 
As I said before, if downman gets in now, we can have a pretty good and 
rock stable transfer manager for 2.6, since almost all work is already done.

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