Re: glibwww2 patches, gtk object



On Fri, 2 Feb 2001, Bibek Sahu wrote:

> 
> Howdy, all,
> 
> 	I've made some changes to glibwww2, since I intend to use it in the
> upcoming future.  However, since I will be moving across the Atlantic on
> Friday, I figured I'd get as much done as I could now and release that work
> to everyone in the hopes that it'll be of use, and maybe that someone will
> do something with it in the interim. ;-)
> 
> 	I noticed that it hasn't been touched in quite a while, but there's
> nothing in the cvs tree indicating that it's dead or will die anytime soon.
> 
> 	Basically, what I've done is create a GtkObject wrapper on top of
> the glib code, which emits signals when events occur.  This ought to be more
> useful to developers at large than was the original set of gnome widgets
> which were linked in directly.
> 
> 	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.

[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).

James.





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