From: mtm@SUMEX-AIM.Stanford.EDU (Mike Macgirvin)
Newsgroups: comp.infosystems.gopher
Subject: RE: Comments about Gopher+
Date: 17 Aug 92 18:37:03 GMT
Reply-To: mtm@SUMEX-AIM.Stanford.EDU
Distribution: comp
Original-To: Brad Clements <bkc@omnigate.clarkson.edu>
Original-Cc: gopher@boombox.micro.umn.edu, gopher-news@boombox.micro.umn.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

>2. The VIEWS return value seems complicated. I don't think its necessary
>   to have the < > around the value. It requires extra parsing to get out of
>   the way. Also, I think the returned value should be in decimal octects,
>   not K.
>
>   Sure, I know, just multiply by 1024, but its not overly clear and the
>   server will most likely know the exact size anyway. 

Agreed. I also have a comment or two on the VIEWS mechanism. Server 
implementation seems a bit unclear; although I presume that a basic model will 
use a filename extension on top of a base selector string to represent different
views. It may be more efficient and flexible to include the unique  selector 
string for a view within the VIEWS information. This would allow differing views
to reside in other places (even remotely), and not tied to a particular filename
extension. There would be tradeoffs either way, and the proposed model isn't 
that bad; but this is probably worth consideration.

>3. A + in the selector allows the server to return the data in three
>   ways,   +count<CR><LF>DATA, or +-<CRLF><DATA><CRLF>.<CRLF>
>   or dump and close the connection.
>
>   Does this imply that the Gopher+ protocol will allow the TCP connection
>   to stay open after the data is returned? If not, then there isn't any
>   point in offering the DATA <CR>.<CR> return mode.

	I would probably agree here. I understand the reasons; with dump and 
close, there is no way of determining whether the data is complete. For most 
stuff, it will be sent with the length. But where the length is unknown, it 
would be difficult to determine whether or not it might contain a lone period. 
Especially since this would most often be used with programs that output text. 
Even a binary file (for instance, a compiled Gopher) can contain a 
"\015\012.\015\012" string, although its size will generally be known. The 
period terminated mode will probably be needed for back compatibility, but seems
quite a bit of trouble for the "+" mode.

>   A month ago I suggested that you allow the server to keep the connection
>   open if it so desires. I received no reply from that suggestion, not even
>   a reason as to why it wasn't acceptable.

	Requests for files quite probably will go to a different server than the
one containing the directory. And the overhead associated with keeping things 
open waiting for someone to choose an item can kill a server, especially if you 
are talking of hundreds or thousands of accesses. This is why we have explicitly
recommended gopher for access to the SUMEX-AIM Info-Mac archives. Maintaining a 
few hundred FTP connections at a time will cripple most Unix servers (and has 
killed our systems in the past). The same number of Gopher clients, while 
producing more connections, have very little impact on the overall load, since 
the connections are extremely short.
	This may seem counter-intuitive, but it is a fact.

>   Servers could still have an idle timeout (which they probably have
>   to have anyway, even in the existing code). They can close the connection
>   anytime between transactions. Clients can detect this easily and re-open
>   if they have to.

	This puts an unfair burden on the server to decide when the client is 
finished. As is, there's a simple transaction. When a transaction is completed, 
that's it; although a server timeout might help to prevent a bunch of people 
from typing away at the gopher port by hand. The transaction model is what I 
like best about Gopher. Open, request, reply, close. It doesn't get any simpler 
than that...

mike