- From: Daniel W. Connolly <connolly@hal.com>
- Date: Tue, 19 Jul 1994 10:33:55 -0500
- To: frystyk@ptsun00.cern.ch
- Cc: www-lib@www0.cern.ch
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