On Monday, December 4, 2017 at 11:06:53 AM UTC-7, Mr. Leveck wrote:
So, I am far from alone in using type h to link to files containing
html from gopher. However, the official standard does not allow this[0]. So, while it works in lynx, I am torn as to the proper method
for this. Type h is supposed to use a URL following a "URL:" directive
in place of the path. However, it is expressly forbidden to place a gopher:// URL in this directive. In this respective type h explicitly
does not act as a file type at all. Amongst its peers (1/5/d/s, etc.)
it stands alone as a kludge. This leaves html content orphanned as it
were.
Thoughts?
[0]gopher://gopher.leveck.us/0/documentstore/1511752069.txt
--
| jynx: leveck [at] leveck [dot] us |
"I always tried to turn every
disaster into | an opportunity." — John D. Rockefeller
I have html documents in my gopherspace and they *render* properly when referenced in menus as the h type and my clients typically render them as html documents, which is to be expected. Are you talking about including html links as a menu item? That is
very different and gets handled by individual servers in different ways and is not standardized among various clients either. Pick your server and pick your client in the transaction!
You might be looking for some standard that doesn't really exist.
Gopher menus point at items that are typically treated as FILES. The menu type can alter the basic behaviors (which are either presenting another menu list (type 1) or displaying the file as text (type 0)). The non-canonical menu type h simply sends a
file to the client that might choose to see it as an html-document to be displayed (not as plain text). Of course, gopher is flexible enough to add new types that clients can handle differently, but that has to be done between a server and a client (for
which there is no particular mechanism as in mime-types) if it is not already an established type.
In the gopher world, if you did anything outside of the simple standards like want to play with HTML, you basically had to construct both the server and the client, which was rather trivial. That is the magic of it. Gopher's greatest strength is
simplicity and flexibility for those building semi-custom client-server systems. HTTP/HTML/CSS is different in that the clients are (relatively) standardized (yet expandable) and you must write servers to deliver something they can use, making the job
much more complicated and less flexible.
Any automation of equating item types with files in Gopher is a bit of "magic" that is not required to be consistent - the original specification of gopher seems to be oriented to the manual (by hand) connection of files to types, and was also oriented
to specific custom servers basically being accessed by specific custom client software, like a university library client-server setup (both ends controlled by you). Universality (many servers being accessed by a particular client software not under your
control) was, in my mind, something of a later development and not particularly well-conceived before www overtook the scene. You are hitting up against this and the inherent differences between HTTP and Gopher protocols.
Gopher+ (the "next" gopher) was going in an interesting direction that fits its academic background, the purposes of UMN creators, and its document/file orientation. It was typically used to provide various versions of the same document/file for the
client to choose between, where the version might be constructed in a different language, or a different file format (html, PDF, txt, zip, whatever), or a different OS (com/exe/hex) but contain the same basic content. It didn't catch on generally, but it
was a particular customization used by a few server/client pairs. (Actually, a great feature that must be handled in very kludgy, complicated, and totally proprietary ways via HTTP.) HTTP/HTML went in a different direction that was not readily
transferable, so Gopher+ pretty much died.
Gopher (and other protocols) are simply an organized way to handle a data stream that tells servers what to send and clients what to do with the received stream (and when to stop receiving). If you program a server to serve up video in a stream, you just
need to program a client to take what is served and render it as a video stream. Gopher just put the smallest sheen of a protocol over passing streams of data to a client. You could tell it to point at a telnet server and let a client figure out how to
handle the fact that telnet protocol data was going to be coming at it. It really was a case-use-specific thing that was just starting to be used generally (with UMN standards) when it was over-shadowed.
Hope that helps with understanding...
Jason Nemrow
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)