[gopher] Re: Item Type Suggestions
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
> > 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
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
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! -----------------------