So, I'm trying to write the 90% of a gopher client that can be in 'pure' web-usable javascript + DOM, in the hopes that there'll be a way to
implement the other 90% in Mozilla's new extension framework soon. Over
the course of my work, I've run into a couple questions I can't find an
answer for:

1. Is item type 3 supposed to be interpreted as a link, or text like i?
2. What is actually the difference between 5 ('dos file') and 9 ('binary file')? Is it just a vague hint on what the binary might be used for?
3. Are there any item types other than i, h, and the ones in RFC1436 in
common use I should be aware of?
4. Are CSO servers common enough that supporting them should be a
priority? Where is the protocol specified? Is there a specified (or
unspecified but commonly understood by clients) URL scheme for them? I'm already translating stuff like 8 and T into URLs, adding another would
be easy.

(Also posted to the mailing list/gmane group, you're not going crazy)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2017-10-20, Keiya <keiyakins@gmail.com> wrote:

So, I'm trying to write the 90% of a gopher client that can be in 'pure' web-usable javascript + DOM, in the hopes that there'll be a way to
implement the other 90% in Mozilla's new extension framework soon. Over
the course of my work, I've run into a couple questions I can't find an answer for:

1. Is item type 3 supposed to be interpreted as a link, or text like i?

I have read that it presents as text and never read otherwise...

2. What is actually the difference between 5 ('dos file') and 9 ('binary file')? Is it just a vague hint on what the binary might be used for?

Gophernicus' documentation refers to type 5 as "archive file " such as
zip, tar.gz, etc. in my proxy code i just lumped up all binary types for
the same processing. In practice this works.

3. Are there any item types other than i, h, and the ones in RFC1436 in common use I should be aware of?

I personally use type s for sound files. ; is recognized as video files.
c as calendar files, M as mime encoded files.

Unless you're writing code to consume these types it should be enough to
lump them in with the binary file types, that is to present them for
download and consumption by whatever software the user has.

4. Are CSO servers common enough that supporting them should be a
priority? Where is the protocol specified? Is there a specified (or unspecified but commonly understood by clients) URL scheme for them? I'm already translating stuff like 8 and T into URLs, adding another would
be easy.

Never came across any but read more here: https://en.m.wikipedia.org/wiki/CCSO_Nameserver
it lists the rfcs

(Also posted to the mailing list/gmane group, you're not going crazy)

--
Leveck

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 20 Oct 2017 17:20:16 -0500, Keiya wrote:

1. Is item type 3 supposed to be interpreted as a link, or text like i?

RFC 1436 describes it simply as "Signals an error condition".
In all implementations I have seen, this translates to a simple text
message (possibly displayed in red).

2. What is actually the difference between 5 ('dos file') and 9 ('binary file')? Is it just a vague hint on what the binary might be used for?

The transmission format is the same, and both file are binaries. So yes,
it's a hint... The RFC is deceptively vague about this: "Item is PC-DOS
binary file of some sort. Client gets to decide.".
FWIW, I'd just threat 5 and 9 (and many others) the same: download as-is.

3. Are there any item types other than i, h, and the ones in RFC1436 in common use I should be aware of?

You might want to take a peek at Motsognir's manual, where I listed the filetypes recignized by my implementation:

http://sourceforge.net/p/motsognir/code/HEAD/tree/trunk/manual.pdf?
format=raw
(p. 9).

Note: The "PDF" format has the item type "P", according to kb142559, but
I have seen many implementation use "d" instead, with "P" possibly
pointing to "picture"...

4. Are CSO servers common enough that supporting them should be a
priority?

In my opinion - don't waste your time with this :) Through my gopherspace browsing, I haven't seen a CSO menu in at least a decade, beside the
occasional ones that are there only for educational purpose, i.e. "how
does a CSO menu look like".

Where is the protocol specified? Is there a specified (or
unspecified but commonly understood by clients) URL scheme for them?

Check out there:
gopher://gopher.viste.fr/1/attic/RFCs/non-rfc

Mateusz
--
gopher://gopher.viste.fr

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/20/2017 11:04 PM, Mateusz Viste wrote:

..
4. Are CSO servers common enough that supporting them should be a
priority?

In my opinion - don't waste your time with this Through my gopherspace browsing, I haven't seen a CSO menu in at least a decade, beside the occasional ones that are there only for educational purpose, i.e. "how
does a CSO menu look like".

I don't know - it seems like the CSO server provides a nice DB backend
that could be expanded beyond "phonebook" lookups assuming it is
actually expandable and isn't a security risk. I guess I see it as a
potential alternative to abusing Type 7 for creating dynamic content in gopherspace.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)