Re: Split libwww from client, ANSI C, and Forms in libwww 3.0
Subject: Re: Split libwww from client, ANSI C, and Forms in libwww 3.0
From: email@example.com (Henrik Frystyk Nielsen)
Date: Tue, 19 Jul 94 16:55:21 +0200
Some comments to the mails from Garrett:
> I don't think those of us that distribute source should be shipping our
> variant WWW libraries with it.
> This pratice is probably the major reason at fault of the libwww
> fragmentation over clients.
> Note that we all haven't hacked up the freeWAIS library that is
> supported; maybe because it's optional, maybe because we didn't go
> changing it to be specific to our client.
> Adopting this policy would place the burden of providing client side
> hooks up to the libwww group. Again, we come to this idea of system
> independent API, but now it is system/client independent API; this is
> already partially done via the GridText functions, but there are other
> places that a client likes to stick its nose in, too.
> Not doing so will continue to support the idea that we can hack up our
> personal libwww just for our client.
I think this is a very ideal situation but I doubt that it will happen
over night. Many of the optimizations in the various library versions
are really good and I hope it is possible to combine them into a
powerfull tool. This is one of the reasons for this mailing list!
BTW: I _have_ hacked the freeWAIS library in order to make it work on
> Was there ever a clear decision wether or not the libwww would be
> completely ANSI C in the future?
The CERN library does already use some ANSI C features that are not
supported by an old C compiler. Examples are void and enum. My feeling
is that it is not so much a question of ANSI C or not but to find a
minimum set of C that can be used on most platforms. Even ANSI C
compiles behave in funny ways! I don't think that it will ever be
possible to use fancy ANSI features like variable-length argument lists
etc. - they simply don't compile on many platforms.
I agree that the ARGS and PARAMS do look strange, but I think we should
make sure not to lose any platforms currently supported before we
remove them. Though, replacements _are_ welcome! Please look at the
page to see a list of platforms supported
Furthermore SCO and MIPS are close to be added as well. So again - no
golden solution to the problem, but I think that it is important to
support a large set of platforms if it is going to be a consistent
library that people don't have to hack.
> Looked at the infomation out at CERN regarding the status of
> libwww. Perhaps I missed it, but I read nothing about forms or their
> implementation inside of the libwww. I am wondering if there is a
> standard forms API inside of libwww, or if there will be in the future.
> Also, I was wondering what level of HTML will the libwww support (along
> the same lines).
> Are these things considered to be a client implementation?
Generally - the HTML side of the library hasn't been touched for a long
time. We hope that this is going to change as Hakon Lie, has started
to look into it. That is also the reason for the lacking support of
About posting, I see two different sides of it:
- The interface between the library and the clients
- The HTTP implementation of PUT and POST
I have been working on a general posting interface that can be used not
only for HTTP, but also NNTP and SMTP (NNTP posting is almost
integrated but no SMTP support currently in the Library). As forms are
a special case of posting, it also goes for this. Please see the
This is a sub document of the page
I have also been looking into how it could be done more elegant in the
HTTP protocol, see
but this is not yet finished. Please give me your comments on the pages!
I have been working on an actual implementation of the posting
interface but as I now have less than 2.5 weeks to finish my master
thesis I have to do this instead :-(. My plan is to write my thesis on
the Web so what you are reading is actually a draft of it!
-- cheers --