[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [gopher] Selector types summary

> > CSO is the same as the old ph. OverbiteFF supports it; this gopher URL
> > talks to a working server at uic.edu:105, queries it for "sachs" and
> > displays both (current) matches:
> >
> > 	gopher://ns.uic.edu:105/2query%20sachs%20return%20all
> >
> > If you do
> >
> > 	gopher://ns.uic.edu:105/2
> >
> > then you will get a requester box. Of course, the itemtype rewriting
> > code in 2.1.1554 does this wrong and offers to rewrite it to item type 1;
> > I will fix this. Just click cancel and the requester will appear.
> thanks for the hints.

Btw, the issue with /2 getting mistakenly rewritten is fixed in build 1556,
along with Jeroen Schot's revised Dutch locale.

> > s is used intermittently for "generic sound." Other de-facto item types I
> > have encountered include p (PNG), d (PDF), x (XML) and c (CSS). OverbiteFF
> > currently supports all of these.
> Then the namespace seems to be overused.

That is a fact :)

I know we talked here about revising this before and didn't really come to
any community consensus. I'm just trying to take a "birds eye" view, but I
would rather not make unilateral moves in my client software.

> How about a simple 'u' item type? The selector should be an URI,
> with the server and port being ignored. This is redundant, but
> redundancy is already a feature of the gopher protocol.

I think hURLs cover that nicely and have the benefit of working with older
clients at the cost of a little extra server complexity.

We'd talked about embedding MIME types into the gopher URL, but that too
never came to any conclusion.

> Of course there is the possiblity to define all 256 possibilites
> of item types with various standards and meta-standards.

Sort of progressing that way already :)

One general idea that was proposed and I personally like is to keep the core
0-9 the same, a-z for specific mappings with a single unambiguous MIME type
and A-Z for class-specific functional mappings that the client should decide.
Other than the infrequently seen "s" we're already doing this, in fact.

------------------------------------ personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@floodgap.com
-- I just love a curious consumer! -- "Ranma 1/2" -----------------------------

Gopher-Project mailing list

Reply to: