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

From: Nick Matavka <[email-masked]>
Date: Thu, 11 Jun 2015 23:20:53 +0200

> ------------------------------
> 
> Message: 3
> Date: 11 Jun 2015 16:05:39 +0100
> From: "John R Levine" <[email-masked]>
> To: "Edward Vielmetti" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: Re: [apps-discuss] gopher-ii standardization process &
> 	personal introduction
> Message-ID: <[email-masked]>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

snipsnipsnip

> It's still very unclear to me what practical problem is addressed here 
> that existing tools don't.

It's still very unclear to me why you should want a screwdriver to drive screws when a hammer is sufficient.  It's also very unclear to me why you should want loo roll with which to wipe your arse when your hands and proper handwashing technique are sufficient.  Finally, it's very unclear to me why the boat was invented, when humans could learn to swim across the ocean and the job would still be accomplished.

Get it?  There is a niche for Gopher; other protocols can fill it, but they do not do the task nearly as well or as conveniently as Gopher does.

> 
> Regards,
> John Levine, [email-masked], Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.
> 
> 

Fraternal regards,
Ed Matavka

---

From: Nick Matavka <[email-masked]>
Date: Thu, 11 Jun 2015 23:23:52 +0200

> Message: 2
> Date: 11 Jun 2015 07:49:58 -0000
> From: "John Levine" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=utf-8
> 
>> After a message on the gopher-discuss list I decided to join the
>> apps-discuss list and see what I could do for the gopher-ii standardization
>> process.
> 
> Hi.  Long time, no see.
> 
>> I'm looking at it as a possible lightweight
>> information system for Raspberry Pi sized devices (small single board Linux
>> systems, sub $25 delivered cost). IETF has COAP in that space already, but
>> perhaps Gopher and gopher-ii can live there too, if you have a system
>> constrained enough to be performant on suitable equipment as well as secure
>> enough because of a deployed base of well-understood and well reviewed code.
> 
> Gee, I wish someone had given us this background a month ago.  I get
> your point, but Raspberry Pi runs linux and it's hard to believe that
> a lightweight web server like lighttpd wouldn't work perfectly well
> and be comparably secure since its code gets a lot of scrutiny.  If
> you want a client, there's always lynx.

Oh, by the way, Lynx talks gopher too.  In fact, I call lynx a gopher client that just happens to talk http as well, rather than an http browser that can do gopher.

> 
> CoAP is intended for really tiny things, with the usual example being
> to tell a smart lightbulb to turn itself on.  Gopher seems too heavy
> for that.
> 
> R's,
> John

---

From: John C Klensin <[email-masked]>
Date: Fri, 12 Jun 2015 00:21:33 -0400

--On Thursday, June 11, 2015 23:20 +0200 Nick Matavka
<[email-masked]> wrote:

> Get it?  There is a niche for Gopher; other protocols can fill
> it, but they do not do the task nearly as well or as
> conveniently as Gopher does.

Nick,

Please calm down.

The question John Levine is asking is not quite the same as
mine, and maybe not as sympathetic, but I think we are both
trying to get answers to a few reasonably straightforward
questions.  To state them differently:

(1) Are there characteristics of the gopher protocol that
respond to problems that cannot be equally well satisfied by a
very stripped-down version of HTTP?  If the answer is "no",
would a version of HTTP that was simplified and stripped down
enough to do the job still be usable from conventional HTTP
clients (aka "web browsers").

(2) If the answer to the question is "yes" and HTTP could be
profiled to an extent, and the profile implemented, so that
there was substantially no footprint or performance difference,
would there still be enough advantage to having a separate
protocol to justify the extra work and desktop or cognitive
clutter.  I think John Levine is assuming the answer is probably
"no".  I am assuming the answer might well be "yes".  But that
doesn't mean there is enough difference between his position and
mine to justify your analogies.

(3) Even if a separate protocol were needed, if it were possible
to implement the thing as a "wrapper" or "overlay" on an HTTP
server, would that be an advantage even if no all
implementations of the gopher protocol were constructed that way?

(4) A similar question applies on the client side.  Do you see
advantages for forcing someone to use separate software (or a
special plug-in or equivalent) to access gopher menus or would
access from an unmodified browser be an advantage?

(5) Your analogies strongly suggest that the main advantages of
a gopher-II protocol over using the web are matters of
aesthetics or other personal preferences.  It is just my
personal opinion, but I don't see much merit in the IETF doing
protocol work to satisfy personal aesthetic preferences.

best,
   john

---

From: Dave Cridland <[email-masked]>
Date: Fri, 12 Jun 2015 09:13:08 +0100

This entire thread is becoming interestingly close to being paraphrased as
a request to detail and document the workings of gopher in order to know
whether it's suitable for a particular task, in order to better inform a
decision on whether to detail and document the workings of gopher.

I suspect that if there's so much energy available to discuss whether or
not we should be doing the work, it'd be more useful to direct such effort
into doing the work...

I'm interested enough to commit to reviewing the drafts.

On 12 June 2015 at 05:21, John C Klensin <[email-masked]> wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 12 Jun 2015 12:13:13 -0400

--On Friday, June 12, 2015 09:13 +0100 Dave Cridland
<[email-masked]> wrote:

> This entire thread is becoming interestingly close to being
> paraphrased as a request to detail and document the workings
> of gopher in order to know whether it's suitable for a
> particular task, in order to better inform a decision on
> whether to detail and document the workings of gopher.

Actually, for me, it is just the opposite.  I'm assuming that
there are tasks for which gopher is suitable.  I'm assuming that
the hierarchical menu orientation of gopher is useful for some
purposes, not merely because it can be lightweight and high
performance but because a more specifically-structured
information model may make it easier to achieve quality and
usability, especially in predictable user interfaces.   I still
believe that our historical principles that favor simple
protocols with few options (rather than the kind of complexity
that comes from "everyone wins by getting their own option" or
similar compromise and harmonization mechanisms) are desirable
and that, all things being equal, they result in implementations
with fewer bugs than protocols and data structures with enough
options and flexibility to try to accommodate all possible
desires.

I believe that the only reasonable criteria for whether this
should be on standards track are evidence that there are people
interested in using the result in real applications, evidence
that there are people able and willing to do the work, evidence
that standards track development within the IETF could add value
to an evolving protocol (as distinct from something that is
frozen and needs only to be documented for historical and/or
informational purposes), and an absence of evidence that the
protocol or IETF work on it will introduce security problems
into the Internet or operational problems for those who don't
implement it -- problems that cannot be solved or sufficiently
mitigated by IETF work on the protocol.

Arguments that amount to "I wouldn't use it, therefore the IETF
shouldn't work on it" or even "I can contrive another way to do
that using existing protocols, therefore the IETF shouldn't work
on it" or "there are equally or more efficient ways to do that"
are definitely not on the above list.  Stated constructively and
with constructive intent, I believe that similar comments and
information can contribute positively to protocol design, but
that still doesn't make them appropriate gating factors for
whether the work should be initiated.

My effort to tease out the potential for one protocol simulating
another or accessing its data structures, or for implementations
of a pair of protocols with shared tooling and code, was
intended to open thinking up a bit and separate those issues
--essentially implementation issues-- from the discussion of
whether the Gopher-II work was worth doing.   Your
interpretation was definitely not the intended one.

> I suspect that if there's so much energy available to discuss
> whether or not we should be doing the work, it'd be more
> useful to direct such effort into doing the work...

I agree... strongly.

> I'm interested enough to commit to reviewing the drafts.

And I have made a similar offer as well as having helped a bit
with the I-D.

    john

---

From: Nick Matavka <[email-masked]>
Date: Fri, 12 Jun 2015 18:58:51 +0200

> On Jun 12, 2015, at 6:21 AM, John C Klensin <[email-masked]> wrote:
> 
> 
> 

Very good questions.  I think what we've got here is a failure to communicate effectively---I don't understand exactly what John's saying, John doesn't understand what I'm saying, this all leads to bad blood, yada yada yada.  I didn't mean to sound irritated; I wasn't---my brevity of communication and forthright diction is simply because I say what's on my mind in simple words.  Basically what I was trying to say was that variety is the spice of life and that some sites work best in a strict hierarchical layout, which http doesn't exactly do.  http is a much more free-flowing protocol.

> clients (aka "web browsers").

I believe there are.  I don't think the words "simplified" and "stripped down" convey the true difference between Gopher and http.  I mean, you could extend Gopher to have a selector for "Shockwave Flash" and have a Gopher client that could run SWF files right inside of itself (like http browsers have flash support).  You could have nearly every link on a Gopher server be an HTML file.  HTML is fully compatible with Gopher.

I think the word "hierarchy" puts the difference between http and Gopher into one word.  FTP is the most hierarchical protocol of all: you log onto an ftp server, and there's two directions to go.  Up and down.  Files and folders are organised into a tree, and you traverse the tree by layers to get to the information you need.  For instance, luckystrike.zip is on ftp.scdp.com/pub/projects/printmedia/tobacco <http://ftp.scdp.com/pub/projects/printmedia/tobacco>.  There's only one way to get to /pub/projects/printmedia/tobacco; you have to click on pub, then projects, then printmedia, then tobacco.  http is not like that.  Since luckystrike.zip is a print media project, AND a tobacco project, AND a project by Mr Donald Draper, there can be a link to http://www.scdp.com/proj/luckystrike.zip <http://www.scdp.com/proj/luckystrike.zip> on any of the 1000+ webpages on the www.scdp.com <http://www.scdp.com/> server; in fact, index.html might link to it, as might printmedia.html, tobacco.html, draper.html, etc.  FTP has a tree topology, http has a net topology, and gopher has something in the middle (call it a hub-and-spoke topology).

I'd actually call http "the bastard son of HyperCard and LaTeX".  It has much more in common with those two than it does with either FTP or Gopher.  Gopher is basically comparable with FTP plus a humanised front-end (i.e. the pages have links with natural-language descriptions and less transparent downloading).  Where FTP might require the user to look at INDEX.TXT to see what the files in the pwd (present working directory) are, Gopher presents INDEX.TXT as a live menu.  Where FTP might require the user to X out of the FTP program and open up Finder to look at the file he has downloaded, Gopher presents the file straight in the Gopher client. 

> mine to justify your analogies.

I think there would be advantage to maintaining a separate protocol, because of topological differences as stated above.  If you could somehow strip out all the crap in http (and I wouldn't even call most of it crap---I love CSS sheets; they're like the LaTeX preamble), you'd still have a fundamentally-net topology.  You'd still have the bastard son of HyperCard and Latex, only instead of having a big beer gut, he'd be anorexic.  

> implementations of the gopher protocol were constructed that way?

It's not only possible but it's been done.  There are two http-to-gopher servers; you can easily browse Gopherspace from an http client.  Rendering a gopher menu in HTML is easy.  The only thing is that HTML isn't made for such a thing---it's fundamentally a hypertext protocol, not a rich-text-and-image protocol.  The key feature of HTML is *hyperlinking* to any page on the Net; even if all image capability and CSS and colours and rich text were taken away, you'd still be left with The Net, simply because the defining feature of HTML is hypertext, and hypertext naturally leads to a net topology.  Rather, if you added live menus and a file viewer to FTP, you'd be left with Gopher.

> access from an unmodified browser be an advantage?

Access from an unmodified browser WOULD be an advantage. Nothing wrong with seamlessly linking a Gopher server to an http page, or the other way round, and having an http browser with inbuilt gopher capability would make obvious sense, simply because code can be reused.  For example, there are PDF plugins for http browsers, and an image viewer, and a sound player.  All of this would make sense in Gopher as well; click on a sound clip and instead of the file downloading and then opening in QuickTime/Totem/VLC, it plays directly in the Gopher client/http browser.

Lynx already does this, and Moz Fx used to.  

> protocol work to satisfy personal aesthetic preferences.

Not aesthetics, but "the right tool for the right job".  Some sites might benefit hugely from a strict hierarchy.  FTP does this but FTP is far from user friendly---as I said, the menus on FTP are very bare and a new user would be hard to teach how to browse an FTP site.  Gopher takes the user friendliness from http and the hierarchy from ftp.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 14 Jun 2015 08:52:02 +0200

On 2015-06-12 18:58, Nick Matavka wrote:
> ...
> I think there would be advantage to maintaining a separate protocol,
> because of topological differences as stated above.  If you could
> somehow strip out all the crap in http (and I wouldn't even call most of
> it crap---I love CSS sheets; they're like the LaTeX preamble), you'd
> still have a fundamentally-net topology.  You'd still have the bastard
> son of HyperCard and Latex, only instead of having a big beer gut, he'd
> be anorexic.
> ...

You keep confusing HTTP (the transfer protocol) with HTML + friends (the 
media types being transferred). This is not helpful.

 > ...
> It's not only possible but it's been done.  There are two http-to-gopher
> servers; you can easily browse Gopherspace from an http client.
>   Rendering a gopher menu in HTML is easy.  The only thing is that HTML
> isn't made for such a thing---it's fundamentally a hypertext protocol,
> not a rich-text-and-image protocol.  The key feature of HTML is
 > ...

HTML is not a protocol at all. That being said, does it have any 
*problems* with "rich-text-and-image"???

> ...
> Not aesthetics, but "the right tool for the right job".  Some sites
> might benefit hugely from a strict hierarchy.  FTP does this but FTP is
> far from user friendly---as I said, the menus on FTP are very bare and a
> new user would be hard to teach how to browse an FTP site.  Gopher takes
> the user friendliness from http and the hierarchy from ftp.
> ...

I fail to see how HTTP prevents you from using it for strictly 
hierarchical information. In what sense is Gopher "better" at that?

Best regards, Julian