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 09:33:23 UTC