[gopher] Re: Item Type Suggestions

[Jason Nemrow <jnemrow@xxxxxxx>]

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 t=
ext version for clients that request ".../0/..." along with the other optio=
ns.  This isn't a criticism of the idea, just clarifying what would have to=
 happen to make gopher0 clients work with this.  I think it is avery workab=
le solution, though it might get very byzantine to have multiple URLs that =
essentially point to the same item.  For example, one would need to put up =
a 9 line for my poor gopher0 client to be able to download the rtf version,=
 as well as a 0(text/rtf) line for the new MIME client (a line gopher0 clie=
nts would ignore).  Could get messy! =20

As a side note, I see a great allure to just use the new version, have noth=
ing for the gopher0 clients, and essentially publish menus without any cont=
ent. We already see something similar in servers that have no 0 type conten=
t (who uses plain text anymore?) and where every item is a 9 downloadable. =
 Makes the gopher0 (sorry, stands for RFC-1436 spec compliant) client usabl=
e but basically feel like FTP for user-friendliness.

I hopr this makes some sense.  Jay

-----Original Message-----
From: "Cameron Kaiser" <spectre@xxxxxxxxxxxx>
To: gopher@xxxxxxxxxxxx
Sent: 7/19/08 10:36 PM
Subject: [gopher] Re: Item Type Suggestions

I thought of something a little earlier today to find a middle ground betwe=
en
being able to handle multiple types if a client wants, but not having to ad=
d
more item types other than generic types.

What would people feel about a URL syntax like this?

gopher://gopher.site.invalid/s(audio/mp3)/music/dada.mp3

The (MIME type) would be optional and used by the server as an optional
request for transcoding or an alternate version, and could be used by the
client to do something special with the file. In fact, the () could be
used for any kind of server specific comments, such as session state
separated by commas, but that's for later.

This also solves our text/* problem:

0(text/css)/document/style.css
0(text/xml)/document/document.xml

At least this way you can have arbitrary MIME types subsumed under general
classes. The MIME type would be optional and could be ignored or employed
by the client as they see fit. A nice middle ground.

Note that servers would need to be updated to support this construction
in their selectors, but only servers that support this selector syntax shou=
ld
be offering it in the first place.

Opinions? I'm trying to balance concerns such as JumpJet's and others on
proliferating item types, but still trying to give people like myself,
John, etc. the ability to optionally specify more complex behaviour without
having to impose anything special on the client.

--=20
------------------------------------ personal: http://www.cameronkaiser.com=
/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@floodgap.c=
om
-- Do me a favour: don't breed. -- "Sledge Hammer!" -----------------------=
----