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

[Zachary Lee Andrews]

IIRC; Lynx supports the classic GET / pseudo selector to link to WWW 
sites.  hURL is a more recent addition.

Ciprian Dorin Craciun wrote:
> 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.
>