[gnome-network]downman description

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

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