Re: Lets keep the web together

Dan Connolly (connolly@pixel.convex.com)
Tue, 01 Dec 92 12:04:51 CST 

Message-Id: <9212011804.AA24775@pixel.convex.com>
To: timbl@nxoc01.cern.ch
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Lets keep the web together 
In-Reply-To: Your message of "Tue, 01 Dec 92 16:52:50 +0100."
             <9212011552.AA01907@www3.cern.ch> 
Date: Tue, 01 Dec 92 12:04:51 CST
From: Dan Connolly <connolly@pixel.convex.com>


>Getting the protocol code and parsing code right and tracking bugs and external
>changes will be some work, I feel that it is important that we do end up with 
>common code.
>
>I know what it is like to have to maintain code on lots of platforms.
>You have to write the code specially. There are W3 code style guidelines in the
>web which say what we found out to be necessary.  It's a pain. Noone is going
>to support 8 parsers on 12 platforms.
>
>I am therefore a little worried about the proliferation of implementations.
>(I know, I'm rather pleased about it too! :-) I would like to see one or maybe
>two definitive libraries around (two, so to test the first one for  
>self-consistent bugs), but not four. I feel that if there are too many, then  
>there will be cases of little things which work on one but not on the others, 
>because there is not enough support effort for each. And we want to keep the  
>quality high, in terms of reliability, conformance, and portability.

Well said. With this in mind, I'd like to take issue with the state
of libWWW:

You can't use any of the parts without using the whole
thing: you can't use the parser unless you use the HText
data structures, including the HTMainText global variable!

The Gopher processing is intertwingled with everything else too.
There should be a GopherOpen() routine, for establishing
a gopher connection and handling seletors and searches, and a GopherMenu()
routine, that handles application/x-gopher entities just
like text/plain and text/x-html entities are currently handled.

Similarly, there should be an FTPOpen, LocalFileOpen, HTTPOpen,
etc routines with an easy way to plug in a WAISOpen routine
when somebody gets around to it.

I should be able to add MIMEMessage(), MIMEMultipart(), PostScript(),
etc. format handling routines alongside the text/html and text/plain
routines.

There is *no reason* for the NOARGS, ARGS1, ARGS2, etc. macros.
You just use the PARAMS() macro in the header, and use K&R style
in the .c file. The only place where this doesn't work is
with varargs foo.

There are #ifdefs for VAX, unix, and ThinkC all over the place.
I'm sure these could be localized.

This is why Tony Johnson started from scratch, and why other
implementors will do the same.

>If you are thinking of a smart extra to EITHER HTTP or HTML then please define
>it and discuss it here on www-talk.  Don't try just to get it out before the  
>next guy. He is probably doing it too, a different way, and theese are all  
>exciting ideas which benefit from being hacked around on the net.
>
>When the idea has come out, we can put it into a tentative "future" spec
>for comment and everyone can work from it.

Again, we see the need for a CSCW platform.

I think that if we archived the www-talk mailing list, and built
an HTTP server that would serve the articles up with hypertext
links between folloups etc, it would be a good start.

If I code up a server in perl that can do this, will somebody
provide disk space and network access?

Dan