XPost: comp.misc
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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)