Groups | Search | Server Info | Login | Register


Groups > comp.infosystems.www.misc > #147

Web vs. Gopher

From Ivan Shmakov <ivan@siamics.net>
Newsgroups comp.misc, comp.infosystems.www.misc
Subject Web vs. Gopher
Date 2018-09-01 10:30 +0000
Organization A noiseless patient Spider
Message-ID <8736utechr.fsf@miko.siamics.net> (permalink)
References <rKXq8K/ojQTpkYaO/J0IQVbw@dont-email.me>

Cross-posted to 2 groups.

Show all headers | View raw


>>>>> Paul Scott writes:

	[Cross-posting to news:comp.infosystems.www.misc.]

	[http://prgmr.com/blog/gopher/2018/08/23/gopher.html]

[...]

 > Why Use It?

 > If Gopher was supplanted by HTTP, why use it?  As with many things,
 > the answer depends partly on your application.  One of the selling
 > points for Gopher back in the day was that it was very light on
 > resources -- no media, just simple text menus.  This makes it
 > attractive today for document-centric applications that don't want to
 > deal with breadth and complexity of the modern web.

 > Try Gopher if you like the feeling of tech nostalgia.  Gopher is part
 > of a bygone age on the net.  The simple fact that Veronica used a
 > database of every Gopher archive to search points to a time when the
 > Internet was small and personal, and it can bring that feeling back
 > in a small, carefully curated and distributed Gopher network.  Retro
 > can be fun.

 > If you prize security, Gopher can be handy.  It's purely text-based.
 > No JavaScript.  None of the tools and add-ons that make the modern
 > net such a minefield.

	I'm going to disagree with this general sentiment.  First of all,
	if you're setting up your own site, JavaScript is by no means a
	necessity.  For instance, my pages (http://am-1.org/~ivan/) are
	ought to be fully readable without it.

	Somewhat of an exception is that I use of MathJax for typesetting
	of mathematical formulae with TeX-like quality.  With Lynx, one
	will read like:

    \[ \begin {align} p (G) &\overset {\text {df}} = \left| V \right|,
    & q (G) &\overset {\text {df}} = \left| E \right|.\\ \end {align}\]

	I don't have much trouble understanding that, but I have to
	admit that I've spent quite some time with LaTeX.

	Another "exception" is http://am-1.org/~ivan/src/JL5desQ9.xhtml,
	etc., yet the only reason these are implemented in JavaScript is
	the sheer availability of the language.  My goal was specifically
	to create a program that can be run nearly anywhere.  (I hope to
	try Emscripten at some point so that I can write C code and
	publish it alongside JavaScript "binaries" that can enjoy this
	kind of portability.)

	The second part of the equation is the server-side software.  As
	an example, I'd like to refer to http://skarnet.org/, and
	specifically /cgi-bin/memstat.cgi, which reads:

	    How much memory is alyss using right now?

	    Kernel excluded, the amount of memory in use is: 73976 kB

	[That is: less than 73 MiB!]

	That may be way more than that of an old-time Gopher server, but
	the host apparently runs a plethora of services (such as ESMTPS,
	IMAP, DNS, etc.) in addition to the HTTP server proper.  Refer to
	http://skarnet.org/poweredby.html for details.

	One specific solution that can be applied when maintaining a
	lightweight Web resource is to limit one to "static" files as
	much as possible.  As shown by the Ikiwiki software, it's still
	possible to implement a "dynamic" Web site that way.

	(Unfortunately, access to prior revisions via Ikiwiki is not
	implemented out-of-box using static files only.  Contributing to
	and commenting on the resource also places additional burden on
	the server, but that's unavoidable.)

	Finally, I'd like to point that the very same Lynx browser that's
	suggested as a Gopher client can be used to read Web as well.
	While, arguably, this doesn't make you safe from any possible
	security vulnerability whatsoever, at least JavaScript-related
	issues are off the metaphorical minefield mentioned above.

	There're two obvious objections to my suggestion.  The first is
	that you, or some other person or group, will find Lynx highly
	unfamiliar.  To which I'm going to counter that, on one hand,
	in the context of a Web vs. Gopher discussion, if Lynx feels
	unfamiliar to someone when it comes to Web reading, wouldn't it
	be any less unfamiliar for accessing Gopher resources?  On the
	other, you can familiarize yourself with it anytime you like.

	A second objection is that "many sites" are going to be
	inaccessible with Lynx.  While this may very well be true when
	absolute numbers are considered, I've found that very rarely I
	find a resource that is both not accessible with Lynx (typically
	due to unwarranted, IMO, use of JavaScript) and is of sufficient
	interest for me to bother.

	There're several possible ways to proceed from there.  One is
	to understand that it may be infeasible, in principle, for that
	specific resource to be made accessible with Lynx.  Think of
	http://earth.nullschool.net/, for example.  Somewhat similar may
	be the case of any Web page used for entering your bank card
	details, although I'm not sure I understand why.

	Another, especially in the case of community Web resources, is
	to find the maintainers' contacts and ask them for their reasons.
	Perhaps they simply didn't think that someone may be interested
	in reading their resource with Lynx and just went with some
	JavaScript-heavy, out of the box solution.

	The third one would be to check for some kind of a public API.
	That won't necessarily make the site accessible with Lynx, but
	perhaps some kind of lightweight (non-browser) interface could
	either be available, or reasonably easy to implement.  (As an
	example, I've contributed to Wikimedia projects for several years
	without ever leaving the comfortable confines of my Emacs.)

	Unfortunately, I'm not aware of any Web authoring recommendations
	that would help an interested party to develop lightweight,
	Lynx-friendly and "document-centric" (unsure I do understand what
	the author have meant by that) Web resources.  But that means an
	opportunity for someone interested in the subject, doesn't it?

 > Ultimately though, use Gopher because you can.

	I wonder if one of these days I'll try HPT.  Or Crashmail 2.

[...]

-- 
FSF associate member #7257  http://softwarefreedomday.org/  15 September 2018

Back to comp.infosystems.www.misc | Previous | NextNext in thread | Find similar


Thread

Web vs. Gopher Ivan Shmakov <ivan@siamics.net> - 2018-09-01 10:30 +0000
  Re:Web vs. Gopher sehnsucht <sehnsucht@fastmail.com> - 2018-09-01 13:34 +0200

csiph-web