1. Forum
  2. Usenet
  3. COMP.INFOSYSTEMS.GOPHER

  • Item Type Questions

    From Keiya@21:1/5 to All on Fri Oct 20 17:20:16 2017
    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)
  • From [email protected]@21:1/5 to Keiya on Sat Oct 21 01:59:05 2017
    On 2017-10-20, Keiya <[email protected]> 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)
  • From Mateusz Viste@21:1/5 to Keiya on Sat Oct 21 05:04:50 2017
    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)
  • From jeff@21:1/5 to Mateusz Viste on Sat Oct 21 12:19:05 2017
    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)