RE: Libwww status

Just as someone who has in the past has also developed a C++ front onto
libwww and only listens lately to this newsgroup I have a couple of
comments:  If the underlying part of libwww were done in C++ it would
strengthen the library and its interrelations.  If it is still a C front end
would this be an issue?  In fact there could be a C and C++ front end with a
C++/C internals?  The internals changes could be performed in a incremental
manner?  Also, wasn't there a vote on this about six months ago?

> -----Original Message-----
> From:	Fred Covely [SMTP:fcovely@bcftech.com]
> Sent:	Wednesday, November 07, 2001 10:45 AM
> To:	www-lib@w3.org
> Cc:	www-lib@w3.org
> Subject:	RE: Libwww status
> 
> Agreed that qualified manpower is the underlying need.
> 
> On the C++/C issue, my preference for C++ is based on a couple of
> potential
> benefits.  First you could presumably use STL for all the low level data
> structures, thus removing some of the bulk of the libwww source, and
> reducing maintenance effort. Second, it makes integration with other C++
> libraries cleaner thus increasing IMHO, the extensibility of the product.
> Portability I don't think is a major issue given the open source efforts
> that are using C++ in a portable manner (Xerces,Xalan come to mind).
> 
> There are some good arguments in favor of fixing and reorganizing some of
> the existing code.  A much smaller effort is one advantage.  Another is
> that
> users of libwww will not have to substantially change their code.  It
> would
> be good to get an idea of what the libwww community thought about a C++/C
> fix/rewrite for libwww.  If there was a consensus opinion then it might
> provide some good direction.  It would probably not be good to embark on a
> rewrite in C++ that no one would use.
> 
> 
> Fred Covely
> BCF Technology
> fcovely@bcftech.com
> (B)760-631-8157
> (C)760-717-9689
> 
> -----Original Message-----
> From: Jose Kahan [mailto:jose.kahan@w3.org]
> Sent: Wednesday, November 07, 2001 6:30 AM
> To: Fred Covely
> Cc: www-lib@w3.org
> Subject: Re: Libwww status
> 
> 
> Hello Fred,
> 
> Let me try to answer your questions. I am sort of responsible for libwww
> at W3C, but from the point of view of the user. I am also a libwww user
> as I ported it into Amaya and this made me the guy who inherited it when
> Henrik left W3C.
> 
> However, I prefered to present myself as a user rather than as the main
> developer. I contribute bug patches, but unfortunately don't have much
> time
> to apply all the patches that are being sent. Other tasks have higher
> priority in my everyday work. This has made my libwww work quite aleatory.
> 
> What I can propose is opening the CVS access to other contributors and
> help roll out new libwww versions. There have been many interesting
> patches
> proposed to the list, not many applied. Thus, we haven't yet rolled out
> a new version.
> 
> Applying patches correctly can be lots of work.  I have to check the
> writing
> style, evaluate the code, see if it doesn't break down things and if it is
> universal enough. Sometimes, I have to modify the patches. Sometimes I can
> do
> apply the patch quite quickly. If applying the patch takes more than a
> given
> time, I can't continue doing it when my other tasks become more urgent.
> 
> Having more contributors would help things work better. I think delegation
> is a good way to do team work.
> 
> Let's answer some of your other questions.
> 
> What we need is more contributors to help apply
> On Mon, Nov 05, 2001 at 02:14:41PM -0500, Fred Covely wrote:
> > I am curious as to the 'strategic' direction of libwww.
> 
> It is in user maintenance mode. The libwww community should maintain it
> or no one else will do it. There's no main maintainer.
> 
> >I have been using it for a while now and believe its a very good product
> >once you can get through the learning curve.
> 
> If you wrote some notes or tutorial, we could add them to the
> documentation.
> 
> > Nevertheless it seems to me that a major rewrite is in order.  It might
> > make a lot of sense to do such a rewrite in C++ using STL and
> integrating
> > with other open source efforts (Xerces comes to mind).
> 
> I don't follow you here. Could you explain better your motivations for the
> rewrite?
> 
> Why C++ and not C? If you want something fast and portable, I don't know
> what
> can be better than C. It's possible to write C++ wrappers to C libraries
> too.
> 
> I think a rewrite in C would be good. My motivations would be:
> 
> 1. There would be a bigger base of people who know how core things work
> and
>    it would help libwww work better. This is for me the most important
> reason.
> 
> 2. Remove things that are bothersome in the architecture. The one that I
> know
>    the best is the way that streams are connected one to the other which
>    sometimes affects how you release resources (for me, it was a big pain
> to
>    find out how to kill a request when the user presses the stop button in
>    Amaya).
> 
> 3. As I said earlier, C is the fastest and most portable language today.
> 
> In a related message, you ask if it's necessary to reinvent the wheel
> or if there's another existing equivalent library. I assume you mean C or
> C++ library.
> 
> Libcurl is a pretty good one. It lists some other equivalent libraries in
> its home pages. The code of the library is quite good and I know the
> developer from another open source project where we both contribute.
> 
> I don't know how complete is libcurl's implementation of HTTP/1.1 today. I
> believe (feel free to correct me) that it doesn't handle pipelining
> requests.
> It handles simultaneous open connections, but this is not answer the needs
> that pipelining does. It doesn't have a document cache either. I am not
> sure
> if it has something equivalent to libwww's non blocking, single thread
> mode.
> 
> On the other hand, libcurl does HTTP PUT, FTP, SSL, and lots of other cool
> things. The API is quite clean and the code is clean.
> 
> The Amaya web client does need the things that libcurl is missing. For
> these
> reasons, libwww is a more appropriate HTTP library than libcurl. In my
> opinion, libwww still has the best HTTP 1.1 compliant implentation today.
> 
> There may be different solutions.
> 
> 1. Make a list of things that our applications use in libwww and
> contribute
>    to libcurl to bring it up to level.
> 
> 2. Rewrite parts of libwww on top of libcurl. Maybe the developers of
> libcurl
>    don't want to add all the extra stuff we need.
> 
> 3. Rewrite the parts of libwww that are broken.
> 
> 4. Rewrite libwww from crash.
> 
> In all of these solutions, manpower is needed. If there are not enough
> volunteers, none of them can be applied. The most important thing is to
> have
> a core team that understand the new library and can react to bugs and
> patches. Without this team and effort, no such project will get to
> survive.
> 
> So, what shall we do?
> 
> > If it is in maintenance mode is there any
> > plans for another release beyond 5.3.2?
> 
> For me, the community decides when we have a new release ready. I would
> chose
> to do one once we applied more patches or if there are serious bugs.
> 
> > We wrote a c++ wrapper around a small
> > part of libwww and are happy with its performance and reliability
> (although
> > we do have some code fixes on top of 5.3.2 that fix memory leaks,
> segf/gpf's
> > etc.)
> 
> Would you like to commit your changes to the CVS database? I can only
> propose to test them by compiling your changes against Amaya. However, if
> there's a bug in your patches, I would expect your help in fixing them.
> 
> -jose
> 
>

Received on Wednesday, 7 November 2001 11:04:48 UTC