> 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.
ABSOLUTELY!
I do not wish to denigrate two marvelous tools and the
considerable effort which went into them, but from a software support and
development environment, both approaches leave MUCH to be desired.
I believe that it is high time we took a very hard look at the
future of WWW and gopher, and retooled them to fulfill the role that they
seem to be headed towards.
We are talking about tools which represent the future of the
Global Internet. They should be developed with a keen awareness of
modularity, useability, portability and supportability.
I'd be willing to participate in such an effort, but lack the time
to coordinate it.
> I should be able to add MIMEMessage(), MIMEMultipart(), PostScript(),
> etc. format handling routines alongside the text/html and text/plain
> routines.
Oh bliss! Oh joy! Would that it were so. <sigh>
-- </rr>
As a matter of conscience, I will no longer support any business in Colorado.