Re: glibwww2 patches, gtk object

[Bibek Sahu <scorpio dodds net>]

On Sun, 4 Feb 2001, James Henstridge wrote:

> On Fri, 2 Feb 2001, Bibek Sahu wrote:
> 
> > 	Also, I've modified src/Makefile.am so that there are now 3
> > libraries: glibwww, glibwww-gtk, and glibwww-gnome.  As you might imagine,
> > the first is based strictly on glib (as per the original code), the second
> > includes my gtk object, and the third contains those gnome widgets which
> > were in the cvs tree.
> 
> I don't know of the value of this much separation.  Each of these mini
> libraries would be really tiny, and just slow down app load time if they
> were shared libraries.  This is one of the problems with libwww, where
> they split it into many small libraries, but to make proper use of it, you
> ended up having to link to almost all of them.

	Well, I don't want every little trinket in a separate shared
library, but I /do/ want to separate the glib code from the gtk code from
the gnome code.  If I'm writing a console app that requires only glib and
needs network support, then I don't want all the gnome and X dependencies in
the app.  And although the widget I made requires Gtk now, I think that may
change with glib/gtk+ 2.x which will include a 'GObject' (don't know for
sure, though).  Still, if I want to create a gtk+ app and use it on systems
that don't have Gnome available, I'd like to be able to do so. :-)

	Besides, considering the standard gnome libraries:

[shadow: /tmp]$ gnome-config --libs gnomeui
-rdynamic -L/usr/lib -L/usr/X11R6/lib -lgnomeui -lart_lgpl -lgdk_imlib -lSM
-lICE -lgtk -lgdk -lgmodule -lXi -lXext -lX11 -lgnome -lgnomesupport -lesd 
-laudiofile -lm -ldb -lglib -ldl

	... I don't think separating glibwww2 into separate libs will make
much of a difference. ;-)

	For the app in question, I intend to support gnome-vfs as well. 
However, the app does not necessarily require gnome, so I'd like to fix up
glibwww and add support for it as well, since glibwww need not require
gnome. :-)

> [snip]
> > 	This code is highly experimental.  I have not tested it on anything. 
> > I /think/ it works, but I won't believe it until I test it.  Also, it has a
> > very severe memory leak -- the requests are never destroyed.  It's a simple
> > fix, but it needs to be done.  One simple way would be to delete the request
> > after throwing the 'load_done' signal, which would literally be a one-line
> > fix.  Another idea would be to keep everything in a hash table.  There do be
> > more ideas, too.  I know it compiles.  That's all I can promise at this
> > time.
> 
> Memory management of the Request objects is one of the big failings of
> libwww.  You will have to be very careful when you free the request
> object, because in some cases (such as when a redirect response is
> received from the server) it will be resurrected after the finalisation
> callbacks have been called (so they can't be used to free the request).

	I'll have to look into that.  Ideally, I'd like the underlying glib
library to take care of deleting the libwww request and call a callback just
before it's deleted (to allow the higher-level system to delete any other
structures associated with the the request).

	When I said 'request' up there, I was actually referring to a
'GLibWWWObjectRequest' structure which contains stuff specific to the
gtk-object implementation.  I'm sorry about that; I should have been more
clear.

> James.

	Thanks for your work on this thus far.  It is appreciated.  :-)

- Bibek