RE: Libwww status

I'm also curious as to anyone's comparison of libwww, curl(
http://curl.haxx.se/ )
, and ACE ( http://www.cs.wustl.edu/~schmidt/ACE.html ).  I gather that CURL
is strictly
client side stuff whereas libwww can be adapted to the server.  ACE seems to
do both, but
I have had very little experience using it.  I think it comes down to
reinventing (or not)
the wheel.

Any input appreciated in advance.

Fred Covely
BCF Technology
fcovely@bcftech.com
(B)760-631-8157
(C)760-717-9689

-----Original Message-----
From: Joel Young [mailto:jdy@cs.brown.edu]
Sent: Tuesday, November 06, 2001 11:23 AM
To: Fred Covely
Cc: www-lib@w3.org
Subject: Re: Libwww status



> I am curious as to the 'strategic' direction of libwww.

There was a post a while ago from one of the former maintainers
that libwww is in "user maintenance".

> Nevertheless it seems to me that a major rewrite is in order.

Yes.

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

It might make a good addition to and make good use of the libraries at
www.boost.org.

> It may make sense to keep a lot of the libwww semantics, while moving
> everything to C++.

Yup, however it should no longer be an application framework.  In the
"old days" many applications that used the web was at its heart a web
application so the framework worked.  Now the web is an auxiliary to
many programs.  Component libraries are a better and more reusable
choice.

Libwww could be split into a network library, a mime library, a
stream library, a parsing library, etc...  Where these components are
already robust with the appropriate licenses the libwww versions should
be scrapped.

A new libwww should use standard types as much as possible to facilitate
interaction (and minimize copying) with other libraries.

There should be absolutely zero global state requiring library user
awareness.

Joel

Received on Wednesday, 7 November 2001 08:54:35 UTC