Re: web

On 2025-01-20, Ben Collver wrote:
On 2025-01-19, yeti <yeti@tilde.institute> wrote:
Ben Collver <bencollver@tilde.pink> wrote:

 >>> In short, gopher is not the web.  It does not use the HTTP protocol,
 >>> the HTML format, nor other web standards such as Javascript.  Gopher
 >>> is a separate protocol that is not directly viewable in mainstream
 >>> browsers such as Chrome and Mozilla.

There's a variety of formats that modern browsers allow viewing
directly, in addition to (X)HTML.  Such as WebM; e. g. (URI split
for readability; tr -d \n before use):

http://upload.wikimedia.org/wikipedia/commons/2/22/
%C2%AB%D0%9C%D0%B0%D1%81%D1%82%D0%B5%D1%80
-%D0%A2%D1%83%D0%BD%D0%BA%D0%B0%C2%BB
_%D0%BE%D1%82%D0%BA%D1%80%D1%8B%D0%B2%D0%B0%D0%B5%D1%82%D1%81%D1%8F%2C
_2020-011_092050.webm

Given the lack of hyperlinking in WebM, I'd hesitate to call
such a file a "webpage."  SVG does support hyperlinks, however,
so I don't see much reason myself to be opposed to SVG webpages.

 >> I contradict.

 >> When browsers appeared, we thought of the web as what was accessible
 >> by them.  FTP, HTTP and Gopher were among this in the early days.

For instance, per http://en.wikipedia.org/wiki/NCSA_Mosaic :

 W> Mosaic is based on the libwww library and thus supported a wide
 W> variety of Internet protocols included in the library: Archie, FTP,
 W> gopher, HTTP, NNTP, telnet, WAIS.

My understanding is that Lynx' retains the libwww codebase to
this day, hence its support for a variety of web protocols well
beyond the modern notion of HTTP(S)-only web.

Call me old-fashioned, but my understanding of what "web" is
/is/ heavily influenced by the example of Mosaic.

 > In the dawn of the Internet some people used a service called FTPmail
 > because it could be faster and cheaper to transfer data over email
 > than over direct Internet connections.  By your logic, one could argue
 > that FTP is email because it was historically used in email clients.

What I think you're referring to falls under the concept of a
/gateway./  There used to be servers that you'd send a web URI
via email to, get it downloaded by a batch web client (such as
Wget) there, and get the result delivered to you in a response
email.  Possibly over a cheaper, high-latency link, such as UUCP.

(Wouldn't make as much sense to request a JPEG this way, only
to download it later over POP3 over SLIP, Base64 and all, now
would it?)

It's not dissimilar to how one can read netnews articles via
http://al.howardknight.net/ .  By itself, that doesn't make
netnews a part of web, nor does it make HTTP a netnews protocol
(even if it /is/ used in this case for netnews transmission.)

Also, "email client" is a misnomer.  An email user agent
would commonly act as /two/ clients: an ESMTP client for mail
submission, and, say, an IMAP client for mailbox access.

A modern MUA, such as Thunderbird, would also embed a web browser
so it can display HTML parts in email /as well as/ images
referenced in those parts, including those that need retrieval
over HTTP.  Hence HTTP client being /also/ part of the so-called
"email client."  (Even though its use would typically be disabled
for privacy reasons.)

Conversely, a traditional MUA, such as BSD mailx(1), would
contain /no/ network client code within at all, relying instead
on system facilities, such as the conventional sendmail(1) MTA
entrypoint.  (Or a program like esmtp(1) posing as one.)
And (or) a program like fetchmail(1) or mbsync(1).

Curiously enough, email transmission between hosts was
originally implemented on top of the FTP protocol; consider, e. g.:

 rfc475> This paper describes my understanding of the results of the
 rfc475> Network Mail System meeting SRI-ARC on February 23, 1973, and
 rfc475> the implications for FTP (File Transfer Protocol).  There was
 rfc475> general agreement at the meeting that network mail function
 rfc475> should be within FTP.

 rfc475> FTP currently provides two commands for handling mail.  The MAIL
 rfc475> command allows a user to send mail via the TELNET connection
 rfc475> (the server collects the mail and determines its end by
 rfc475> searching for the character sequence "CRLF.CRLF").  The MLFL
 rfc475> (mail file) command allows a user to send mail via the data
 rfc475> connection (requires a user-FTP to handle the command but
 rfc475> transfer is more efficient as server need not search for
 rfc475> a special character sequence).  [...]

Not only this predates the transition from Transmission Control
/Program/ ("IPv3") to Transmission Control Protocol + Internet
Protocol (TCP/IPv4), but apparently even the first (?) formal
specification of the former in 1974:

 rfc-index> 0675 Specification of Internet Transmission Control Program.
 rfc-index>      V. Cerf, Y. Dalal, C. Sunshine.  December 1974.
 rfc-index>      (Obsoleted by RFC7805) (Status: HISTORIC)
 rfc-index>      (DOI: 10.17487/RFC0675)

The dawn of the Internet, indeed.

 > One could also argue that because when browsers appeared, they could
 > view HTML content over the Server Message Block protocol, that CIFS
 > is also the web.  Such arguments strike me as disingenuous.

I'm not aware of such browsers, aside of the fact that some
Windows-based ones have allowed \host\path syntax in place
of proper URLs.  I doubt that aside of the syntax, the browser
had any SMB/CIFS client code within itself, however.

So far in this thread, I see two possible definitions of the
web: one I've suggested that boils down to "documents with
hyperlinks based on URI syntax and semantics", and the other,
that to me sounds like "what Google says."  (I don't see Mozilla
as a major driving force behind the web this day and age.)

And I /do/ understand why Google would push for HTTP(S)-only
web (even with "HTTP" now being expanded to mean /three/ similar
in concept, but otherwise mutually incompatible protocols.)
And I won't envy any Google manager who'll have to explain to
the investors a decision that lowers the profits in the short
term, and hardly promises any tangible benefits later, such as
the decision to add (and take responsibility maintaining) a
Gopher client to the browser.

I do not understand why people outside of Google have to be
bound by the decisions of their management, however.  The web
browser I use supported Gopher since before Google existed;
I fail to see why "Google saying so" has to be a sufficient
reason to at once stop deeming the protocol part of the web.

As to the definition I've suggested, I could only add the
requirement for the relevant protocol(s) to have at least two
independent implementations.

My understanding is that Gopher does have such implementations.
No idea about CIFS, but given (if Wikipedia [1] is to be believed)
that Microsoft has never made good use of it, it sounds doubtful.

Hence: not web.

[1] http://en.wikipedia.org/wiki/Server_Message_Block#CIFS