- From: Vic Bancroft <bancroft@maioriello.com>
- Date: Wed, 7 Nov 2001 08:22:53 -0500 (EST)
- To: <www-lib@w3.org>
Warning, post written during first cup of coffee.
On Tue, 6 Nov 2001, Joel Young wrote:
> Some time earlier Fred Covely wrote :
> > 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".
This situation is quite suitable for an opensource project.
> > Nevertheless it seems to me that a major rewrite is in order.
>
> Yes.
Humm, who is going to test it under all the currently supported platforms?
> > 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).
What will happen to "pure c" programs who are using Libwww ?
> > It may make sense to keep a lot of the libwww semantics, while moving
> > everything to C++.
Why not just reconstruct a new library ? Put it in Library/src/cpp
perhaps. There are only 117 c source files and 151 headers to translate.
> Component libraries are a better and more reusable choice.
It is possible to produce component shared objects with a smaller
scope and memory footprint by just adding additional targets to the
Library/src/Makefile.in . . .
> Libwww could be split into a network library, a mime library, a
> stream library, a parsing library, etc...
Sort of like,
lib_LTLIBRARIES = libwwwutils.la libwwwcore.la libwwwtrans.la
libwwwstream.la libwwwcache.la libwwwdir.la
libwwwfile.la libwwwftp.la libwwwgopher.la
libwwwmime.la libwwwhttp.la libwwwnews.la
libwwwtelnet.la libwwwhtml.la libwwwapp.la
libwwwinit.la libwwwmux.la libwwwxml.la
> Where these components are already robust with the appropriate
> licenses the libwww versions should be scrapped.
Ouch, why the vicious attitude ?
> There should be absolutely zero global state requiring library user
> awareness.
Huh, well, I guess so, is this a simple desire for reenentrancy or the
more ambitious goal of functional programming ???
more,
l8r,
v
Received on Wednesday, 7 November 2001 08:44:43 UTC