Subject: Re: [apps-discuss] apps-discuss Digest, Vol 89, Issue 15

From: Nick Matavka <[email-masked]>
Date: Fri, 12 Jun 2015 19:14:00 +0200

> On Jun 12, 2015, at 10:13 AM, [email-masked] wrote:
> 
> Send apps-discuss mailing list submissions to
> 	[email-masked]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/apps-discuss
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
> 
> You can reach the person managing the list at
> 	[email-masked]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of apps-discuss digest..."
> 
> 
> Today's Topics:
> 
>   1. Re:  gopher-ii standardization process & personal
>      introduction (John C Klensin)
>   2. Re:  apps-discuss Digest, Vol 89, Issue 13 (Nick Matavka)
>   3. Re:  apps-discuss Digest, Vol 89, Issue 13 (Nick Matavka)
>   4. Re:  gopher-ii standardization process & personal
>      introduction (John Levine)
>   5. Re:  gopher-ii standardization process & personal
>      introduction (John C Klensin)
>   6. Re:  apps-discuss Digest, Vol 89, Issue 13 (John C Klensin)
>   7. Re:  apps-discuss Digest, Vol 89, Issue 13 (Dave Cridland)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 11 Jun 2015 15:49:11 -0400
> From: John C Klensin <[email-masked]>
> To: Julian Reschke <[email-masked]>, Edward Vielmetti
> 	<[email-masked]>, John Levine <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [apps-discuss] gopher-ii standardization process &
> 	personal introduction
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> 
> --On Thursday, June 11, 2015 18:53 +0200 Julian Reschke
> <[email-masked]> wrote:
> 
>>> HTTP/HTML5 is a pretty big protocol, and Gopher (even
>>> gopher-ii) is a much smaller protocol. The minimum Docker
>>> image serving up a Gopher server is a good design target -
>>> you just expose port 70, do just your tiny little thing, and
>>> don't try to construct an entire web service out of it (and
>>> track HTML5 etc etc ad nauseum).
>>> ...
>> 
>> 
>> HTML5 is huge, HTTP/1.1 without optional parts is not.
>> 
>> Maybe it would be more interesting to define media types for
>> Gopher interactions and run them over HTTP/1.1 with GET and
>> POST?
> 
> As I read the earlier postings, I was thinking about something a
> little bit similar.  Let ask a different question or pair of
> questions (with the understanding that these are questions --
> I'm not trying to advocate anything.  Please forgive me if this
> is naive - I'm trying to ask questions that are close to
> end-user level.
> 
> It seems to me that "Gopher", as seen by end users is a pair of
> things: an access protocol and a hierarchically-organized
> distributed information model.  From the same point of view, the
> Web is an access protocol and a mesh (and/or hypertext)
> distributed information model.  There is a principle in graph
> theory that one can use a mesh to simulate a hierarchy but not
> vice versa.  At the same time, that simulation inherently makes
> resource that are thought of in hierarchical terms harder for
> non-experts to organize and think about.

It also wastes mesh.  HTTP was written with the mesh in mind; so arbitrarily constraining it to access only the layer directly above and the layer directly below is sort of foolish, I think.  Plus, how would such a constraint work?  I mean, there are servers that do this---they take a Gopher server and turn it into HTML---but I don't think the protocol should be rewritten simply as a language for HTTP-to-Gopher gateways.

> 
> If that is correct, should we be thinking about one or both of:
> 
> (1) A media type and/or markup structure that is optimized for
> hierarchical menu-like structures and that is very easy to use
> rather than, e.g., laden with options for doing really fancy
> things in a mesh environment.  I don't know what that structure
> would be; I'm fairly sure it isn't unrestricted HTMP5 even
> though HTML5 could almost certainly be used to simulate it?

HTML5 *is* used to simulate it as a point of fact.

Really fancy things aren't restricted to http; I've seen html files with javascript and css on a Gopher server.  The only thing they lack is hyperlinks.

> 
> FWIW, it is fairly clear to me that such an arrangement should
> provide --either directly or via a well-defined URN-like
> arrangements-- for alternate locations/ copies of the same
> resources, both menus and targets, so this wouldn't be a
> completely trivial subset of HTML.

Alternate locations and copies defeat the point of Gopher---they turn the tree back into a mesh.  The point is to keep it as a tree.
> 
> (2) A profile of, or variant on, HTTP that would be really
> lightweight and that might, if necessary or useful, be optimized
> somewhat toward the above data type in the same ways that HTTP
> itself has historically tended to assume HTML.  Maybe that
> subset would be HTTP 1.1, as Julian suggests, but maybe it would
> be sensible to look at, e.g., current thinking about security
> and privacy and avoid, again for example, separate "insecure"
> and "secure" protocols on different ports in favor of SASL-like
> negotiations.
> 
> Now, even if the above are just thought experiments, are they
> useful in figuring out what "Gopher-II" means and where it would
> fit into both user and restricted device or application models?
> 
> Again, just questions to see if we can clarify and converge a
> bit on our thinking.
> 
>       john
> 
> p.s. Hi, Ed.
>

---

From: Nick Matavka <[email-masked]>
Date: Fri, 12 Jun 2015 19:22:15 +0200

> ------------------------------
> 
> Message: 4
> Date: 11 Jun 2015 22:18:43 -0000
> From: "John Levine" <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]>
> Message-ID: <[email-masked] <mailto:[email-masked]>>
> Content-Type: text/plain; charset=utf-8
> 
>> distributed information model.
> 
> It's also a mesh -- entries in a gopher menu can point anywhere.

De jure, yes, it is a mesh.  But de facto, Gopher tends to be organised in a hub-and-spoke sort of arrangement.  A small mesh connected to another small mesh above it by its centre, and connected to another small mesh below it again by its centre.  

>  Back
> in the dim mists of the 1990s I recall briefly using a server that
> served both gopher and web from the same set of files.  The menus
> turned into either gopher menus or simple web pages with lists of
> links.  Everything else was just content which it served more or less
> the same either way.  Poking around in gopherspace, I see several
> gopher servers available that appear to do roughly the same thing.

Such a thing is indeed possible with Gopher but you'll notice that the net is less convoluted---there are patches of mesh connected by single strings, rather than mesh throughout.  I don't know if that's just sort of current Gopherspace ethos or if it's always been like that, but personally I like it.

Plus I *love* GopherVR and I think the protocol that it runs on should be standardised as a matter of principle.  If you can make such a beautiful and elegant piece of software for a protocol, that protocol deserves to be standardised.  You certainly couldn't make HTTPhenge work... but Gopherhenge is alive and well!

> 
> It seems to me that a simple profile of http would do everything that
> gopher2 is intended to do, require about the same server resources,
> and be usable in a lot more clients.
> 
> R's,
> John