W3C home > Mailing lists > Public > www-lib@w3.org > October to December 2001

RE: Libwww status

From: Fred Covely <fcovely@bcftech.com>
Date: Wed, 7 Nov 2001 10:46:14 -0500 (EST)
To: <jose.kahan@w3.org>
Cc: <www-lib@w3.org>
Message-ID: <NDBBIGEEOLAKIPFCDMLNAEFHHDAA.fcovely@bcftech.com>
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 10:48:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 April 2007 18:18:40 GMT