I figure I could put my two cents worth in here.

For my part, the Gopher protocol is that which is rendered correctly by the final version of the UMN Gopher client, which can be found here these days: https://github.com/jgoerzen/gopher
I also stumble on it in a few modern distros for Linux and the BSDs.

If the UMN gopher client can't render something properly, that something isn't gopher, no matter if it is a "new" type or a different rendering of a menu that can be seen as an improvement. Gopher could be haltingly flexible in its design, but a lot of
that wasn't realized when most clients were written in their day. The point of using an older protocol (besides being a lot easier to code) is that older existing clients on older OSs and older machines can still make use of it. If you add new
functionality that breaks older clients or makes some menu items unusable or inaccessible to older clients, you are just not doing gopher anymore. I don't want to have to re-code a commodore 64 gopher client because someone decided to redefine gopher and
make everything more incompatible...

This isn't a call not to do cool new things, only not to call such new things *gopher* or imply that what you are doing is compatible with gopher. When what you do doesn't work with the UMN gopher client, just call the thing something else and make sure
you offer a reference client/server pair (as UMN did) that adheres to your new standard and then name it something else and then get a new port number assigned while you are at it. If it is on port 70, it should be gopher or gopher+ compliant so as not
to confuse existing clients by using the gopher port and then not conforming to the UMN client standard. This is why we create standards in the first place!

Though underdeveloped since infancy and practically abandoned not long after birth, the gopher protocol is de-facto defined by the last UMN client and that simply becomes "the" standard. Deviate if you like, but use a different name and port number to do
it, please.

Also, that means that there is no "secure" gopher protocol. The UMN client couldn't do SSL, so it ain't gopher. Besides, gopher was never conceived as secure - anyone could access it and it was read-only by design - what needed to be secured here?

Broadly, I personally see no problem with "gopher-ish" derivative protocols/clients/servers being advertised or discussed in this newsgroup. Anything like a simple, fast, and easy-to-code transport deserves a home here alongside gopher.

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

On Friday, May 4, 2018 at 2:42:53 PM UTC-6, Jason Nemrow wrote:

I figure I could put my two cents worth in here.

For my part, the Gopher protocol is that which is rendered correctly by the final version of the UMN Gopher client, which can be found here these days: https://github.com/jgoerzen/gopher
I also stumble on it in a few modern distros for Linux and the BSDs.

If the UMN gopher client can't render something properly, that something isn't gopher, no matter if it is a "new" type or a different rendering of a menu that can be seen as an improvement. Gopher could be haltingly flexible in its design, but a lot

of that wasn't realized when most clients were written in their day. The point of using an older protocol (besides being a lot easier to code) is that older existing clients on older OSs and older machines can still make use of it. If you add new
functionality that breaks older clients or makes some menu items unusable or inaccessible to older clients, you are just not doing gopher anymore. I don't want to have to re-code a commodore 64 gopher client because someone decided to redefine gopher and
make everything more incompatible...

This isn't a call not to do cool new things, only not to call such new things *gopher* or imply that what you are doing is compatible with gopher. When what you do doesn't work with the UMN gopher client, just call the thing something else and make

sure you offer a reference client/server pair (as UMN did) that adheres to your new standard and then name it something else and then get a new port number assigned while you are at it. If it is on port 70, it should be gopher or gopher+ compliant so as
not to confuse existing clients by using the gopher port and then not conforming to the UMN client standard. This is why we create standards in the first place!

Though underdeveloped since infancy and practically abandoned not long after birth, the gopher protocol is de-facto defined by the last UMN client and that simply becomes "the" standard. Deviate if you like, but use a different name and port number to

do it, please.

Also, that means that there is no "secure" gopher protocol. The UMN client couldn't do SSL, so it ain't gopher. Besides, gopher was never conceived as secure - anyone could access it and it was read-only by design - what needed to be secured here?

Broadly, I personally see no problem with "gopher-ish" derivative protocols/clients/servers being advertised or discussed in this newsgroup. Anything like a simple, fast, and easy-to-code transport deserves a home here alongside gopher.

For fun, you can access a UMN client, pointing at my gopher server ( gopher://quix.us ) by telnetting to quix.us. I haven't got the file downloads worked out yet, but you can play with it.

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