[gopher] Re: Item Type Suggestions

["Jay Nemrow" <jnemrow@xxxxxxx>]

I am sorry that I am forking from the discussion, but I'm just
realizing something that might render all the good discussion moot
about how to form URLs.

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 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.

If I am confused about what you all are talking about, I apologize,
but it seems we are barking up the wrong tree with URLs.

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.

Jay

On Mon, Jul 21, 2008 at 9:56 PM, Cameron Kaiser <spectre@xxxxxxxxxxxx> wrote:
>> > What would people feel about a URL syntax like this?
>> > gopher://gopher.site.invalid/s(audio/mp3)/music/dada.mp3
>
>> I am thinking that this would necessitate multiple types of the same basic
>> file for this to work with older clients.  THere would need to be a plain
>> text version for clients that request ".../0/..." along with the other
>> options.
>
> I see your point, and maybe I think there is a better way to use the idea.
> Mind you, the only case where multiple items *would* be needed is in order
> to offer multiple views of the same item (I used the word VIEWS on purpose:
> Gopher+ would probably handle this a bit better), or if you wanted it to
> imply the server would do transcoding or translation (if possible).
>
> In the immediate term, though, let me make a new suggestion: using the
> syntax to extend item types without actually adding any. A URL like
>
> gopher://gopher.site.invalid/9(image/tiff)/pictures/venusdekilometro.tif
>
> would still be seen by a regular "uninformed" client as a binary to be
> saved, but a MIME-aware Gopher client could use the MIME data to determine
> something special. We wouldn't need a TIFF item type in this case -- we
> could just case it as a special case of "binary."
>
> Similarly, for the MP3 above, we could simply extend the s itemtype with
> the correct MIME type. A client that doesn't care just ignores the selector
> and uses the itemtype like it always did. This would allow "the right thing"
> by both fat Gopher clients and thin ones.
>
> Eventually, yes, it would be nice to extend it by using it for semantics
> of translation, but given the well-taken point you give above, maybe that
> would be something better offered in a limited circumstance or as part of
> a different scheme (like Gopher+).
>
> --
> ------------------------------------ personal: http://www.cameronkaiser.com/ 
> --
>  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@xxxxxxxxxxxx
> -- Long live the Commodore 64 -- eight bits are enough! 
> -----------------------
>
>
>