Re: libwww

PHB:
|>> >        The big question then is how hard would it be to rebong Mosaic
|>> >onto the current release of CERN libwww?

EWS:
|>> Please bear with me as I digress a bit:
|>>
|>> The main problem is that libwww is not the same across all Mosaics.
|>> NCSA's three versions of Mosaic use 3 different libwww implementations,
|>> all loosely based on your version 2.09, but with very different mods  
made.
|>> The Mac and UNIX versions differ the most, since neither of those  
platforms
|>> are actually using libwww for HTML parsing.  Upgrading either the Mac
|>> or UNIX version of NCSA Mosaic to any current CERN version will be a
|>> large task.

Need this be such a large task as it seems?
Basically, if I understand it right, the problem is that
within libwww after 2.14, the protocol modules output structued
streams (ie parsed SGML token streams) as opposed the unparsed streams
of previous versions.  The Mac and X Mosaic hypertext widgets do their
own parsing, and so expect an unparsed stream.

No problem... it is trivial to get a unparsed stream, by tacking on
the HTMLGen module. This means just changing HTML_new(HTStructured*)
call HTMLGen to get a normal stream, and then set up the widget
to take input from the stream.

	HTML_new(HTStructured s) {
	   return MyOldHTML_new(HTMLGen(s))
	}
	
libwww is event-driven.  That is, the streams are writeable,
and network events trigger the pipeline of processing,
which ends up driving the widget. If a browser has diverged to the extent
that the widget needs itself to loop, calling a getc() routine or
whatever, then one can *even* fix that, but you need the multithreaded
3.0 libwww. Basically, you make
a simple buffer stream which accepts the output from the libwww machinery.
When the widget gets control, it calls some read routines which check
the buffer and if it is empty call
the libwww event handler until some data has appeared.

These differences between browsers may look big, but in fact it
only takes a few lines of code to adapt the libwww machinery to
fit into them.

If there are other problems then please list them here.

EWS:
|I'm CCing the list on this to invite a wider base of opinions on this
|situation.  The issue is the sharing of a common code base for W3 software.
|The previous message to this list mentioned CERN's soon-to-be-released
|versions 2.17 and 3.0 of libwww.  The problem is that most browsers which
|use libwww have had to modify it considerably, especially the browsers which
|are running on non-UNIX platforms.
|
|In addition to mentioning the NCSA versions of Mosaic and ours, Spry's
|AirMosaic is still based on libwww 2.09, as far as I know (Chris?).  EINet's
|MacWeb and forthcoming WinWeb appear to be based on CERN code.  I presume
|they found it necessary to make substantial modifications as well.

Have we got contacts for EINET people? On the list?

|What *actions* can we take to remedy this situation?  Given the number of
|code changes that have taken place in the various incarnations of libwww,
|I do not think it is likely that any non-UNIX browser will be able to
|upgrade to 2.17.  At the least, it will require substantial effort, and
|we don't want that effort to be repeated when 2.18 comes out.

There is no need to repeat effort *if the changes are folded in*.
The problem with the NCSA Mosaic libwwws is that there was no folding
in, and little effort to make the hooks needed fit in with a common
library -- witness the lack of commonality even within NCSA.
If CERN had had the manpower to go mine for the diffs and put them in
retorospecively then theings might have been differnt, but it doesn't
work unless there is some two-way communication: there are constraints
form both the app side and the lib side, and these have to be discussed.

CERN had manpower problems, but with W3O that will
be relieved.  And our attitude has always been to fold in anything
which people need (unless it it really dirty!) so that anyone who
has helped us fold in things can take future versions with zero changes.

Obviously occasionally there have been changes to the API.  These have been
occasional, and the API is very similar to what it was at 2.0.

Tim Berners-Lee
CERN

Received on Wednesday, 13 July 1994 16:52:23 UTC