Complete.Org: Mailing Lists: Archives: gopher: July 2008:
[gopher] Re: Item Type Suggestions

[gopher] Re: Item Type Suggestions

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: <gopher@xxxxxxxxxxxx>
Subject: [gopher] Re: Item Type Suggestions
From: Jason Nemrow <jnemrow@xxxxxxx>
Date: Mon, 21 Jul 2008 12:21:12 -0600
Reply-to: gopher@xxxxxxxxxxxx

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=
being able to handle multiple types if a client wants, but not having to ad=
more item types other than generic types.

What would people feel about a URL syntax like this?


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:


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

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

[Prev in Thread] Current Thread [Next in Thread]