Re: [gnome-network]downman description

[Manuel Clos <llanero eresmas net>]

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
> re-implemented.

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
> code.

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
> case.

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
http://llanero.eresmas.net