[gopher] Re: Item Type Suggestions

["Jay Nemrow" <jnemrow@xxxxxxx>]

Just thinking about it, a gopher client has to be able to carry
intelligence from the transaction that identifies item type (and as we
are thinking about, MIME), which is carried in the menu entity from
server to client; hold onto that item type (MIME) knowledge through
the subsequent transaction, and then render the results according to
that item type (MIME) information that was actually picked up in a
previous transaction.  Gopher works essentially by a
2-transaction-per-result model, where (on the client side) first a
menu is requested then pulled (transaction one), then the desired
server selector string is sent then the actual item is received
(transaction two).  Both transactions have to happen because part of
the first transaction (knowledge of the type of the item) is needed to
properly render the results of the second transaction.
Two-transactions-per-result.

Now, to my limited understanding, http was designed (at its root) with
a 1-transaction-per-result model.  The client sends a whole slew of
information with its initial request (heck, I think it would reveal
the color of your underwear if it could sense that) and, based on
whatever the http server found useful or relevant, it sends back what
was requested (perhaps even telling you what browser you are using,
since the client so willingly offered it up among a hundred other
facts in its request).  One very information-filled request is made,
one response is given (under basic http).  One-transaction-per-result.

If you were to compare it to people meeting at a party, httpclient is
the guy who tells you their entire life story along with the first
handshake.  Gopherciient is the reserved guy that only asks a few
questions and gets the information he wants.  You know everything
about httpclient but you know absolutely nothing about Gopherclient
(who doesn't even give you enough information to remember if you
talked to him before).  Very different conversational style.

I think there would be a problem (which you may be trying to convey)
in trying to essentially make a http client (Firefox, in this case)
function like a gopher client.  Past browsers (I think) actually had a
gopher transaction engine (for lack of a better description) embedded
in them and simply used the rendering engine (often Gecko) to display
menus and content in the browser window - the http transaction engine
would be circumvented for gopher client work.  What you are trying to
do now is to make a http transaction engine work like a gopher
transaction engine (because the original gopher transaction engine was
removed or never included in new browsers).  The very large problem is
that you are asking a one-transaction-per-result engine to work (in
simple way) as a two-transaction-per-result engine.  It sounds like
this is the basic problem, if I am reading between your lines
correctly.

I think we are getting lulled into pointless discussions by how
Mozilla/Netscape/Firefox1-2/SeaMonkey turn server selection strings
(which it knows about since it sent them to the gopher server) into
pretty URLs that we see on the address bar.  I can' t see tons of
relevance between the two, besides that the server selection string is
the back part of the URL ( I know, seems very relevant, but hang in
there).  The gopher transaction engine (remember, I made that term up)
isn't sending that "0" in "gopher://quix.us/0/bonzo/info.txt"; to the
server, it is just useful (from a user perspective) because if you
bookmark that (or get it from a web page), the gopher client can
immediately request the resource directly without requesting and
pulling the containing menu entity first.  Essentially, it becomes
your client's storage of associated item type (from the programmer's
perspective), allowing a gopher server to give you the result in one
transaction (basically like a http server would).  **But remember, you
didn't get that item type number in the URL from the gopher server
directly in one transaction!!**  The client stuck it there from a
previous transaction that it held information from (or from you typing
it in).

I figured this out because, when I used mgod as my gopher server, I
was getting "gopher://quix.us/0bonzo/info.txt"; in my address bar.
mgod doesn't give a leading slash (/) in its menu entity lines, so the
browsers weren't showing it either in the URL, which make it look
ugly.  The browsers were building a url based on information it had
collected over a few transactions and it works very well, only because
there is some sort of gopher-specific transaction engine that tracks
all of this and provides it to whatever code renders the URL.  Like I
said before, the server isn't providing that URL in one pass - it is
interpolated from at least two transactions.

We are all (I include myself up until a few minutes ago) trying to
look at how gopher works through an http lens, it seems to me.
Cameron has made a gopher client out of a http browser (with a http
transaction engine), which is a heck of an accomplishment.  Now we are
pondering how to add MIME to this (well, you folks are - I am that
obnoxious "let's just live with the way it was" guy) and everyone is
trying to understand the correlation between "magic strings" and URLs
that are seen on Firefox and that if you get the MIME type in the URL
somehow, it will pass to and do something intelligent on the server
(which I think someone proved was wrong with GopherS).  ***Remember
that no item type information ever passes from the client to the
server according to the protocol, no matter what a manufactured URL
says!***  Don't bother trying to actually send it!  The server tells
the client what the item type is, not the other way around.  Cameron's
idea of putting the MIME type like this
"gopher://quix.us/0(text/plain)/bonzo/info.txt" is fine as long as it
is understood that nothing except the last part "/bonzo/info.txt"
should ever be sent to the server.

After looking at the output that was posted from GopherS, I suppose
that the older browsers that could do gopher natively simply stripped
off the protocol/servername ("gopher://quix.us";) and the following
slash ("/"), processed the next character as the menu Item type
(knowing that gopher specified that menu types are only single ASCII
characters), said to itself "hey, The next thing I am getting is a
text file!", sent what was left to the gopher server as the "magic
string", and waited for the text file to show up.  As long as we obey
the protocol on building "magic strings", every client will get back
what they ask for.

If everyone is still gung-ho about extending gopher to handle MIME, I
still agree that putting it in an added tab field in a menu entity
line ***on the server*** is the way to go in order to preserve
backward-compatibility.  It doesn't have to be done with all the cruft
Gopher+ was asking for, just simply adding a tab and the mime-type in
ASCII right before the closing <CRLF>.  Older clients will ignore it
(if programmed according to protocol) and new browsers can use it to
do smarter rendering.

***On the client side***, I think Cameron can use whatever convention
he wants to make passing the item type through two transactions work
easiest for his programming.  None of the stuff between the
protocol/hostname string ("gopher://quix.us";) and the actual "magic
string" ("/bonzo/info.txt") needs to be considered by the gopher
server because it should never be sent to the server.  (Actually, the
gopher server doesn't care about the protocol/hostename string either,
but the client needs that to know what server to connect to.)  Cameron
could use that "between space" to pass whatever information he wants
on to the next transaction, so his
"gopher://quix.us/0(text/plain)/bonzo/info.txt" would be perfectly
fine, as long as it is understood that this convention is strictly
client-only and the server will only ever see "/bonzo/info.txt".

[Last second addition --- Actually, I think the parenthesis don't
process well in urls - this might be better --
gopher://quix.us/0/text/plain/bonzo/info.txt -- which would be easy to
parse as mime types are always in two parts.]

My point is that this MIME extension would look different on the
server side menu entity:

0<tab>Bonzo Info<tab>/bonzo/info.txt<tab>quix.us<tab>70<tab>text/plain<CRLF>

Than it will look in the address bar of the Firefox/OverbiteFF client:

gopher://quix.us/0(text/plain)/bonzo/info.txt

and there is ***no programming reason*** they should look the same.
Server creators would obey the new MIME convention on the server side.
 OverbiteFF should process this as it does every other line in a menu
entity (may need a change in the parser and then in whatever function
handles the item type now), and it can produce whatever URL in the
address bar that works best for Cameron as the OverbiteFF programmer.
It doesn't require big rewriting of code on the server side and it
should only require a string parser update and a new MIME association
function in the client (oversimplification from the guy not coding
this).  Duck Soup!

A crucial thing to remember is to break and discard the right part of
the URL in creating the "magic string" that actually goes to the
server.  The "gopher://quix.us/0(text/plain)" part should not be sent
to the gopher server!  Please don't try to alter the protocol in order
to pass such metadata to the server in a client request (ungopherly to
the point of protocol death) - if you desire that, just work with
http, which is a wiz with such fat client stuff, and forget gopher.
If you want to add MIME to gopher (as opposed to gopherish http), it
must be the server providing MIME metadata to the client, not the
other way around.

Jay


On Tue, Jul 22, 2008 at 4:42 PM, Cameron Kaiser <spectre@xxxxxxxxxxxx> wrote:
>>  I would support a variation where we'd write off gopher+ as the
>> complete failure it is, and just stick mime fields at the end of the
>> menu records.
>
> How would the statefulness problem be solved, though? I don't object to
> this from a compatibility perspective, but it does make it impossible for
> an arbitrary resource to be typed without knowing the menu it was referenced
> from (which could be one of multiple menus).
>
> If there's a workaround for this, I'm cool with that idea, but like I say,
> not even HTTP enforces statefulness on clients (cookies and authentication
> excepted, but they are not obligatory portions of the protocol).
>
> For something like Overbite to use such a field, it would have to pass data
> to itself using its own degenerate URL format, which means we're back to
> square one (each instance of Overbite accessing the server preserves no
> internal state, and managing such a thing with globals would be fraught
> with thread synchronization problems). Can anyone think of a way around that?
> If so, I'll support it.
>
>>  Or maybe we could drop the menu format and move to XML, ha ha.
>
> Evil. ;-)
>
> --
> ------------------------------------ personal: http://www.cameronkaiser.com/ 
> --
>  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@xxxxxxxxxxxx
> -- BOND THEME NOW PLAYING: "Moonraker" 
> ----------------------------------------
>
>
>