Re: Split libwww from client, ANSI C, and Forms in libwww 3.0

In message <9407191455.AA27417@ptsun03.cern.ch>, Henrik Frystyk Nielsen writes:
>
>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 don't think it's time for the "functionality freeze for and
porting integration" phase of libWWW development. The dang
thing has never had a decent design review! And there are no
regression tests.

There are some structural issues in the library that I'd like
to see resolved before we start saying "It can't change because
we'll break wierd client XXX, YYY, and ZZZ."

I can't seem to find the time to integrate my changes into
the released libWWW, but...

	* Interaction between HTFormat and HTRequest, e.g.
	HTStreamStack: the www/present notion isn't sufficiently
	general. I suggest an alternative to where client apps
	register sets of
		(format, quality, cost, callback, callback_arg)
	for each of the types that they understand natively.
	It's hard to explain, but I've got the code working
	(in Python, but the idea will port to C).

	See http://www.hal.com/%7Econnolly/pywww/HTFormat.py

	We can get rid of all the www/* stuff: www/unknown,
	www/present. HTGuessStream becomes
	HTFormat_infer(filename, first_few_bytes) and gets
	called by the protocol module, if necessary.

	* There are a lot of unnecessary .h files included in
	lots of modules. e.g. every module includes HTUtils.h,
	which includes tcp.h, so every module depends on all
	sorts of wiered networking #ifdefs and such even though
	it might be something like HTChunk.c which uses nothing
	outside the ANSI C standard library.

	* The protocol modules are still pretty monolithic. There
	should be an FTP.c module that just does FTP, and doesn't
	know anything about HTML, MIME, or anything else. The
	python library includes such a module in ftplib.py.
	On top of that, I built FTPLoad.py:

	See http://www.hal.com/%7Econnolly/pywww/FTPLoad.py

	(yes, it works with SOCKs. Python has a socket module,
	and I developed a work-alike module that uses SOCKS,
	and modified ftplib.py slightly to do things in
	a SOCKS-friendly order.)

	* The makefiles are AFU. Use Imake or GNU autoconf please.
	Do whatever Tcl/Tk does. That is one package that is
	clean, general, and easy to use. We should use it as
	a model for lots of things.

I'm prototyping this python version of the libWWW API using a python
interpreter with Motif and the Mosaic widget linked in, plus 
HTFileWriter.c, SGML.c, and a few other libwww modules linked in
with a little glue code.

The problem is that this is a "skunkworks" project, so I can't seem
to get caught up to any released version of libWWW.

I had all the .h for 2.15 clean up w.r.t ANSI/POSIX, and then 2.16
came out with all new .h files built from .html files. I don't have
a linemode browser handy that I trust to do the .html->.h correctly.
So I'm stuck for a while until I get that installed.

I tried to build the latest linemode browser from source, but it
barfed with an undeclared identfier somewhere, and using that
BUILD script and twelve different directories to build the dang
thing is such a pain for development work that I didn't even look
into the build problem any more.

I realize there's a lot of whining in this message, but I'm a
little frustrated because I've thought about this a lot, and I'm
quite sure I've got good solutions, but I don't have the resources
to package it all up.


Dan

Received on Tuesday, 19 July 1994 17:33:29 UTC