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

[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: Cameron Kaiser <spectre@xxxxxxxxxxxx>
Date: Tue, 22 Jul 2008 07:25:48 -0700 (PDT)
Reply-to: gopher@xxxxxxxxxxxx

> The whole notion of putting filetypes in the URL is something that 
> doesn't really work all that well already, since it breaks relative 
> linking.

I agree wholeheartedly with this. My proposal is more of a transitional
idea until "something better." Eventually there will be some sort of file
coming along that people will want to support, and at least this method
is backwards-compatible with any client as well as forwards-compatible
with clients that want to use the information.

> If we are still going to put MIME types into URLs, why not put them at 
> the end?
> 
> Either:
> 
> gopher://blah.com/0/foo/baz.txt?text/plain
> 
> or
> 
> gopher://blah.com/0/foo/baz.txt#text/plain
> 
> The item type is not really for the server's benefit anyhow.

Well, it might be in the future if the server wants to understand the
specified type as a directive to transcode or translate (admittedly getting
ahead of ourselves). UMN gopherd already does this sort of with selectors
like 1/some/directory.

The problem with the ? syntax is that baz.txt could be a mole, meaning
text/plain would be seen as an argument, not a type.

However, the # delimeter has some possibilities. Let me think out loud and
you tell me if I'm missing something:

- A client that doesn't understand # transmits the whole selector to the
server. The server would simply have to throw the #... portion away, and
the client would use the regular item type 0.

- A client that understands # to indicate a specified MIME type would take
that off, transmit the remainder of the selector, and understand whatever
data to come back as the specified text/plain.

Where this breaks down is item type h, since # might indicate an HTML anchor,
but that has a well-defined behaviour anyway which fortunately already
exists and can be handled as a degenerate case by the browser (it should "just
work").

Did I cover all bases? I would be fine with that syntax instead.

-- 
------------------------------------ personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@xxxxxxxxxxxx
-- We aren't your science project! -- Akane, "Ranma 1/2" (OAV 9) --------------



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