[gnome-network]downman description
- From: Manuel Clos <llanero eresmas net>
- To: gnome-network-list gnome org
- Subject: [gnome-network]downman description
- Date: Mon, 22 Sep 2003 14:59:36 +0200
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]