Re: [gnome-network]downman description

Rodrigo Moya wrote:
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

Well, basically I will drop the ftp.c and http.c code and use gnome-vfs, provided gnome-vfs does everything, so no rewrite here. Using the async interface will mean calling a func instead of starting a thread and hook to the events, again, no rewrite, just change the way things are called. The download thread will contain _less_ code, but I don't see why it must be reimplemented.

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

hmm, the second thing I dont like about downman again is how the daemon
is implemented. It seems from the code that it uses UNIX sockets to do
the client->daemon communication. Am I right? If so, that code, again,
serves no purpose at all for the Trasnfer Manager in GO, since we
already have Bonobo to do that communication. So all that code from
downman has to be rewritten also.

So you want a bonobo based daemon. Yes, that mean rewriting the communication stuff. Doing a bonobo call instead of calling the "connect_local" function in utillib.

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.

string commands right? That's what I think I've understood from the

Yes, numbers much like FTP.

Download class? where is that class? You mean the one in daemon?

Yes, daemon/download.{h,c}

how are clients notified? via the UNIX sockets stuff?

Again, all this is not needed at all in the gnome-vfs case, since
gnome-vfs does evertything for us (except notifying the clients, which
we can do with a BonoboListener, for instance). So, again, there is not
much code we can reuse here :-(

Yes, it is that simple. I could have encapsulated the file description in a "Connection" class, so it will now be easier to modify.

what does local_connect mean? That you can connect to remote download
managers also (ie, is there a remote_connect call)?

No, there isn't but is planned, so you can connect a a daemon running on another machine. This is left for the future, if switching to bonobo will make it simpler I will think about it.

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.

I told before, that this can be moved into the connection call so that it starts automatically much like bonobo. This is not a big deal.

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

what is the 'fd' stuff, that is also in client_new in daemon/? Is that
the UNIX socket (or whatever) you use to communicate with the daemon?

Yes, the "Connection" object. I didn't do encapsulation here. fd is your connection with the daemon. I started implementing it with simple things that worked.

again, what is the purpose of exposing a 'fd' in the API?

again, the still not encapsulated thing :)

moving the daemon and util lib is useless since, as I've understood, we
have to rewrite a lot of things, as stated above.

I don't think there is such rewrite since it is a little part compared to what is currently implemented in downman, but feel free to disagree.

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.

The system tray icon will be another client. Not everyone likes to work the same way, some people like the system tray some prefer the floating window. Since all the code from utillib and the New Download dialog are shared, writing the client is just matter of writing a system tray app.

well, to integrate with GNOME you have to use more than glib :-) First
of all, you dont have to reimplement things that are already available,
like the sockets/whatever communication you have in the client->daemon

I didn't want it to depend on bonobo, remember that implementation started a lot of time ago. I have just been working on other things. I have keep it pretty modular, so it is easy to change modules.

following the HIG is the only thing of these that makes it to integrate
with GNOME :-) Using data types in glib is nice, but not enough.

I already say I will use gnome-vfs. It is already using glib, gtk, libgnome, bonobo, following the HIG, libxml, planning epiphany integration, ... well, it currently uses gnome-vfs to get mime-type icons.

Plus other itheas like:
	- daemon / GUI separation

right now, if I understand well, you dont have this separation, so
again, a lot of work (maybe a full reimplementation) of the daemon seems
to be needed.

Why do you say this? Didn't I explained it well in the previous mail? where don't you see the separation?

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.

Well, the downmand stuff, loading/saving projects, the scheduler, the configuration, the client handling, the Projects, the Servers, the download stuff doesn't need to be reimplemented.

Your points can be summarized to:
- Use gnome-vfs where I'm setting up the connection myself. This is just cutting code. - Use gnome-vfs async interface where I have a different thread. This is just not creating a thread but listen to events. - The daemon should be bonobo based, so that there is no need to create the unix socket and use just bonobo for communication. Again just a matter of cutting some code.

I will say that this is easy to do, instead of saying that is similar to starting from scratch.

yes, but the architecture does not fit, since there are a lot of things
that need to be reimplemented.

Again, I don't see that _lot_ of things and I don't see the reimplementation. I will do the gnome-vfs stuff to see how big the changes are.

Dude, it's not done :-) If I've understood correctly (and sorry if I
didn't), most things need to be reimplemented to fit gnome-vfs and
Bonobo in. The client->daemon stuff is to be rewritten, using a CORBA
interface, Bonobo listeners to notify clients, etc. The daemon code
needs to be reimplemented to remove all the FTP/HTTP protocol stuff and
replace it with gnome-vfs, which already has the asynchonous stuff.
Also, it seems the daemon code only supports downloads, since it does
not seem to contain code in the HTTP/FTP code to log in and upload a
file. Or maybe I missed it.

It means working on something that has the same architecture, that already works but needs to shift to other way of working file the uris (gnome-vfs) and that you can keep testing.

These most things is just switching to gnome-vfs and bonobo. Perhaps is better that I do the changes first so we can discuss it better.

Sorry if I sound a bit unpolite, it is not my intention at all, but you
keep saying that downman fits in with the archictecture we're talking
about, and from what I've seen, it needs almost to be
rewritten/re-architected to match that plan. I'd like to be wrong, and
really have downman be the solution to this discussion. This would end
up my current headaches of tying to keep you guys in agreement :-) and
will make you work in other gnome-network things.

Is there any definition of the architecture/plan somewhere? I haven't seen / readed it.

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.

I could even switch Gnome Download Manager to use libgnomenetwork, because the UI _is_ separated from the daemon.

I will better work on the gnome-vfs switch. Since gnome-vfs and bonobo are your bigger (and only) worries I will work on it. Downman is not only a simple http and ftp client getting bits and doing communication over a traditional UNIX socket.

So, to make it clear, are gnome-vfs and bonobo switches your worries? does downman + gnome-vfs + bonobo fit in?

Manuel Clos
llanero eresmas net

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