[gopher] Re: Gopher Protocol Issue

[David Allen <s2mdalle@xxxxxxxxxxxxx>]

On Wed, Dec 27, 2000 at 01:36:58PM -0800, Cameron Kaiser wrote:
> > So how do you reconcile this?  Is it "correct" behavior for a gopherd
> > to terminate ALL lines with "\r\n" even if that's not part of the
> > original data it's sending?  (In the original gopher RFC, it
> > specifically says that for directory listings, each line should be
> > terminated with "\r\n".  But for regular files, it doesn't say)  This
> > would be intensely lousy, since it would mean that the server wouldn't
> > know how many bytes it was going to send unless it looked through the
> > files and counted the number of occurances of that pattern before
> > hand, which isn't very efficient.
> 
> Actually, some clients will break without the \r\n termination of lines
> in text files -- TurboGopher for the Mac is one of these offenders.

Breaks as in, it won't display the data properly, or what?  I've never
used this client.  Well, I'll fess up, I'm a gopher baby, I've only
used lynx, netscape, UMN gopher, and my own pre-alpha client for a few
months. 

Ah, so of course this brings up the question of whether or not you
should follow the protocol, buggy clients be damned, or potentially
break software.  

> Gopher+ is sort of a nebulous extension and there are a lot of inconsistencies
> in it, the one you mention being one of many. It's a lot of good ideas that

Well see that was part of what the question was.  Does gopher+
*require* that each line end with \r\n even when that isn't part of
the data being sent?  I'm not sure whether or not in this case the
problem is just a bad idea in the code of UMN gopherd, or if it's
actually a braindead requirement of gopher+.

And the whole period doubling thing...frankly, a protocol should never
force you to send data other than what you want to send.  I.e. if I
run "diff downloaded_gopher_file /var/gopher/file_being_served" I
shouldn't ever get any different IMHO.

> should be implemented but aren't in a developer-friendly form with all the
> kinks accounted for. That's why I gave up trying to create a wholly compliant
> implementation in Bucktooth -- it only supports enough Gopher+ to tell a
> client bent on sending G+ requests that it shouldn't do that, and that's all.
> I have enough intricacies in the core protocol to worry about without G+ :-(

When you say "developer-friendly" are you referring to the type of
situation where you would realistically have to scan an entire file
for certain patterns before being able to accurately report to the
client how many bytes were going to be sent?  Servers shouldn't have
to do all that.

Well the issue I was trying to get around was that UMN gopherd which I
was patching was ALWAYS sending -1 to the client telling it that it
didn't know or was too lazy to calculate file sizes.  I'm guessing
that always sending -1 was just the developer's way of avoiding these
issues.  But IMHO how much data the server is going to send is an
important figure, since it allows the client to show the user what
percentage you're at.  (i.e. is this just a big text file that's going
to be done downloading in another 10 seconds, or am I going to have to
wait 3 more days for it to finish?)

The clients I've seen though never send G+ requests unless they know
they can.  (I.e. when listing the contents of a directory, each dir
entry has a "\t+" at the end of it.)  

> Before further development continues, I think there should be some work on
> getting the Gopher+ sketch turned into a much more solid proposal.

The gopher+ info is quite old - are the people who wrote that still on
the map in terms of gopher activity?  The document I've got is dated
July 30, 1993, written by Farhad Anklesaria, Paul Lindner, Mark P.
McCahill, Daniel Torrey, David Johnson, Bob Alberti, 
Microcomputer and Workstation  Networks Center Computer and
Information Systems University of Minnesota

I plead ignorance - how is that type of thing done?

-- 
David Allen
http://opop.nols.com/