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