>You may say "But CGI is for servers". Yes, it is, but you can look
>at those external protocol handlers as servers. You could handle
>unknown protocols by connecting to an HTTP server and giving it
>the full URL and have it gateway for you. That's done all the
>time by proxy servers. What you've done is cut out the HTTP middleman
>and directly run the gateway. With the HTTP server out of the way,
>CGI logically follows as the interface. Well, it _does_ make sense,
>I may just not be explaining it well.
The problem with taking a proxy server sort of approach is that we have
huge customers who want to send information to people who have no Internet
connection at all. Yet the publishers only wants to support one interface
and one protocol. No problem for plain documents, but as soon as you want
to add functions that would normally be at the server, such as search and
retrieval, relevancy ranking and the other stuff we do, you have to
integrate it into the client somehow.
Re-reading that, I think I should point out that *most* of the intended
audience have an Internet connection. It's just that for some small
percentage, there isn't one at all, and for a larger subset, it may be
intermittent, slow, etc.
Nick
--------------------------------------------------------------------------
Nick Arnett "We are surrounded by insurmountable opportunity."
Verity Inc. -- Pogo (Walt Kelly)
narnett@verity.com