Re: finger url, copyright caches (again)

Michael A. Dolan (miked@CERF.NET)
Wed, 24 Aug 1994 14:09:13 -0700

At 01:35 PM 8/24/94 -0500, Daniel W. Connolly wrote:
>In message <199408241605.JAA05432@nic.cerf.net>, Michael A. Dolan writes:
>>At 04:17 PM 8/24/94 +0200, Reed Wade wrote:
>>>Is it _really_ needed? No, but for a different reason. I wanted
>>>this for end users who want to have pointers to finger servers.
>>>Setting up more servers (finger gateways) is anti-scalable and
>>>doubles the load on the net. I'd much prefer the gopher hack to
>>>that.
>>>
>>>But yes, ease of use is the only actual reason for it.
>>
>>Reed, don't be so modest.....
>>
>>The same argument could be applied to any non-http URL - why not a CGI for
>>everything; and then, necessarily, an httpd gateway in every pot ?
>
>Not true. A CGI gateway on one host does not give all clients access
>to all finger servers in a scalable fashion. (Not to mention
>firewalls, etc.)

I was *not* suggesting that CGI and proliferated httpd's was a reasonable
solution. In fact, just the contrary. It was a tongue-in-cheek proposal.
Sorry - not enough smileys :-)

>The gopher: hack does. The gopher protocol is a complete superset
>of the finger protocol. (well... I haven't researched it carefully,
>but the common "finger foo@bar" is expressible as a gopher URL).
>
>It's not the case that you can "tunnel" other protocols like this.

I couldn't tell from your response whether you're in favor of a finger
scheme or not. So, if we're in raging agreement, sorry, but lest there
are still non-believers.....

It is possible to extend gopher functionality to support other protocols,
just like it was for CSO. You can make gopher send just about any command
stream to any port (as long as you don't want/need ftp-like negotiation).

There are two problems with this (including existing CSO support in my
opinion):

1. How to support other command features of the protocol that gopher's
simple command output can't handle ?

2. How to add intelligent support for the returned "document" type ? An
unmodified gopher client can (at best) interpret the reply data stream as
"text/plain". Whereas an intelligent multi-protocol-browser would intuit
(from the scheme in this case) the data stream content and be able to
intelligently format (perhaps to HTML, or not) for display.

In my mind, the purpose of a new scheme is to both A) provide a potentially
rich command set for that protocol (ie not just live with gopher capability),
and/or B) provide an intelligent means for interpreting the results. Either
need/purpose is sufficient cause for a new scheme.

In today's, multi-protocol-capable browsers, it is not *necessary* to
extend gopher to new protocols. The fact that it was done in the past,
and the fact it *could* be done in some limited way again does not
seem to justify exclusion of a new scheme.

Long live finger.

Mike
-----------------------------------------------
Michael A. Dolan <mailto:miked@cerf.net>
TerraByte Technology (619) 445-9070, FAX -8864