[gopher] Re: Item Type Suggestions

[Cameron Kaiser <spectre@xxxxxxxxxxxx>]

> No part of the URL is ever passed to the client.  Once a connection is
> made with a gopher server, only menu entites, texts, or binary files
> are sent by the server - no other information passes.  The client only
> sends back a "magic string" (an RFC 1436 term) that is one of the
> server selector strings, and the server gives back what the client
> requested through the "magic string".  URL conventions are only used
> in reference to the field that contains the name of the server in each
> line of the menu entity and so building different URLs is pointless.

I'm not sure I understand what you're getting at here. There is some
precedent for doing URL preprocessing; every server that supports moles
does it necessarily. If I'm not getting your point, I apologize.

> I think the convention set out in gopher+ is the better way to add the
> mime extension, as an added tab field after the ones established by
> RFC 1436.  All decently built gopher0 clients ignore anything on a
> menu entity line between the port number and the <crlf>, so this is
> where additional metadata (like mime types) logically could go without
> breaking older clients.

This would be nice except it requires such clients to be stateful -- i.e.,
I need information about the menu a particular item is referenced from to
be able to handle that item. The client would need to keep in memory the
prior menu to know the item type. Not even HTTP requires that (the MIME type
is in the headers).

> Also, if we are to deal with mime types at all, I am thinking that all
> of them must be put under the 9 item type, no matter what, just to
> keep old clients from breaking.  If you put a .doc file under the 0
> menu type, the old client wants to dump that to screen as text and you
> will see gibberish and probably crash things.  Everything that doesn't
> fit into the established types will have to be 9 item types, as far as
> I can see.

I think this is definitely a reasonable thing to do for the vast majority,
although as I say things like text/css could truly be itemtype 0 because
they are just text. However, an RTF or a DOC should be a 9, I agree.

I do want people to understand I'm proposing something like this as a
transitional means to expand the item type base and still work with existing
clients, pending a migration to either Gopher+ or even John's proposed
Gopher++. At least this is something that is simple to implement now, breaks
no clients, is purely optional and not obligatory, and is entirely server
dependent meaning only the servers that support it need worry about it.
I won't dispute it's a little hackish. :)

-- 
------------------------------------ personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@xxxxxxxxxxxx
-- You'd PAY to know what you REALLY think. -- J. R. "Bob" Dobbs, 1961 --------