[gopher] Regarding "title" (and other special) informational items [Was: Re: RFC submission?]

[Ciprian Dorin Craciun]

On Fri, Jan 2, 2015 at 9:59 AM, Mateusz Viste <mateusz at viste.fr> wrote:
> [...]
> document on piratepad.net looks more like a bag of wishes. Also, it
> describes the usage of some xml-like tags in gopher (title), which by
> itself, is a heresy to me. [...]


Although I tend to agree with Mateusz regarding the simplicity appeal
of the Gopher protocol (at times perhaps too simple), and the fact
that "bolting" new features on-top of the existing protocol (like the
title information items) detracts from this simplicity towards
convoluted specifications and incompatible implementations.

However the title information items, which replace the empty selector
with the "TITLE" selector, made me think a little about how structured
Gopher menus actually are right now...


First of all, is there any Gopher client which actually implements
this title information item feature?  Because I've seen it documented
it that RFC proposal I thought so, but Overbite doesn't seem to
implement it (although it only took one line of JavaScript to make it
so).  (BTW `lynx` doesn't even implement `URL:...` selectors...)


Back to the topic of how structured the Gopher menus are, currently
the Gopher menus are technically just a flat list of items with no
differentiation between the various items (except their type).
However if we look at a few Gopher sites, like the ones below
(randomly picked from a list I've once seen), we can easily observe
that the editors do impose a certain structure inside the menus
(especially the "root" menu).

  gopher://gopher.floodgap.com/
  gopher://pongonova.org/
  gopher://jgw.mdns.org/
  gopher://gopherpedia.com/

Most of the editors seem to have split the menu into multiple
sections, where the first one serves as a title and foreword for the
entire menu (usually on the root menu, but absent on lower levels);
followed by a few sections featuring a section title and then either
text or links belonging to that section;  and sometimes ending with a
footer.  The way to "mark" these sections varies, but is clearly
visible from the information items where such a section starts and
where it ends.

However as stated there is currently no technical solution to convey
this organization.


Therefore it makes me wonder if perhaps a first incremental
enhancement (without touching the existing protocol) to the Gopher
ecosystem wouldn't be to improve the structuredness of these Gopher
menus?  This would allow the Gopher clients to better present this
information to the user, by perhaps creating a table of contents
(maybe in a sidebar), or (in case of mobile devices) collapsing the
sections (or showing only the first few items), etc.

Such a change would not affect in any way the Gopher protocol (which
in my opinion is just enough to be useful), nor would it impact
existing clients or servers.  It only adds meta-data in the form of
informational items, which already informally exist on most Gopher
sites.


For example I would suggest something like described below, where the
selector of an informational item would be:

* `title` item (one per menu), whose text would constitute the title
of the menu;  (like in the current proposal RFC, except only one;)

* `section-begin` and `section-end` items, which like the `title` item
would mark the beginning of a section whose title is the text of the
`section-begin` item;  (I'm not certain if nesting should be allowed;)
 (although the `section-end` would make it seem much to close to XML,
this is not the case, and it would be useful to implement collapsing,
while keeping visible some other information not part of the section;)

* `meta` items, which could provide additional information about the
current menu, like for example the date the menu was last updated, the
authors, etc.;  the text of these items should follow the RFC822
header convention, i.e. `Author: Ciprian Craciun`;

* `adornment` items, which are currently used by the Gopher editors to
mark section begins, ends, blank-lines, etc.;  these informational
items don't actually provide any useful information, therefore a type
of client we are speaking about here could just skip displaying;

* perhaps also `heading-begin`, `heading-end`, `footer-begin` and
`footer-end`, which although provide information, most of the times is
identical to all menus belonging to the same site, therefore they
could be always collapsed;


To my defence I don't propose to transform Gopher into a crippled
hyper-text solution, I'm only raising a flag about existing practice
and how we can improve it beyond the current state and standardize it.

So, how about these (heresies)? :D
Ciprian.