[gopher] Re: meta: item types, etc.

[Cameron Kaiser <spectre@xxxxxxxxxxxx>]

> Maybe just using gopher+ VIEWS feature would help? Implementing just a 
> subset of gopher+ in clients and servers shouldn't be very hard and 
> wouldn't probably cause much protest from gopher+ critics.

No, I agree that ultimately the fact that gopher+ uses MIME will solve the
problem. However, there will still be people using the earlier protocol, so
there still needs to be some mechanism to formally define a new itemtype.

To wit, the item types in question were over text/xml and text/css. I'm
thinking designating them as x and c, but I don't want to do such things
unilaterally unless I absolutely have to; while I already did that with p
and d and that seems to have been okay, sooner or later there will be a
clash.

Right now, the type list I work off of looks like this:

0-9  the usual suspects
s sound file (wide type -- handled internally as application/octet-stream)
; movie file (don't ask me, this is something I've seen used historically;
        wide type)
h HTML
g GIF
p PNG
d PDF
I generic image
T 3270
i info

My proposal is:

- avoid typographical characters due to URL encoding problems, with ; as
  the sole historically tolerated exception (deprecated but supported)
- 0-9 are well-defined and atomic and don't change
- a-z represent specific MIME types for document classes (s being exception)
  such as PDFs, images, RTF, HTML, XML, etc.

  immediate changes:
  j JPEG
  t TIFF
  b BMP
  r RTF
  x XML
  c CSS
  f favicon
  k XBM (eKs Bee Em)

  s deprecated but supported

- A-S represent specific MIME types for media or interactive classes such as
  WAV, AIFF, AAC, MP3, MOV, AVI, OGG, etc. (I being exception)

  Since many of these share the first character, reserve mnemonic types for
  free or common codecs such as MP3 or OGG.

  immediate changes:
  O OGG
  H tHeora (sorry)
  M MP3
  A AVI
  S WAV
  Q QuickTime MOV

  I deprecated but supported
  
- T remains 3270
- U-Z reserved for application specific internal handlers and can be used
  freely with client-defined behaviour for internal URLs (such as using a U
  item type to run a different client handler, etc.)

-- 
------------------------------------ personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@xxxxxxxxxxxx
-- God may be subtle, but He isn't plain mean. -- Albert Einstein -------------