Alex Schroeder 🐝 is a user on octodon.social. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.
Alex Schroeder 🐝 @kensanata

OK, I think I finally have a good version of my server which serves a wiki as a gopher site and allows people to edit pages. Of course no gopher client currently supports that, but this page now shows how to achieve that using nc, for example.
alexschroeder.ch/wiki/2017-12-

· Web · 4 · 4

@kensanata good stuff! a type that allows uploading an arbitrary chunk of text is a decent compromise that doesn't overcomplicate the procotol. it does take a bit more work from the user but it's definitely a good starting point

@kensanata just to check: does the server read until the stream closes, or does it accept a dot as a terminator?

@aeonofdiscord It reads until the stream closes (I think: the library docs just talk about a "chunk"). The reason I'm not looking for the dot as a terminator is because I want to upload images as well and didn't want to have two item types, one for text files and one for binary files.

@kensanata honestly the dot-terminator thing is really weird to me considering the protocol is designed to close the connection after the file is done sending

@aeonofdiscord Yeah, I was wondering whether my server should just keep listening. I mean, it would make browsing even faster, I guess?

@kensanata that only works if you're sending text or a menu, though, you still have to close after a binary

@kensanata @JTE if the protocol included control signals/metadata (so you didn't have to rely on closing the port to indicate the end of a binary file), then I'd say keeping the connection open might be worth it. It seems like the typical use case is to 'explore' a single server for a while; eliminating the slight delay every time the user reconnects might make menu browsing a bit nicer

@aeonofdiscord what, who, hey, cat's awake. I have no particular say over what goes into gopher protocols though? I should read up on what's in the protocol and see if there's any client/server "supported feature list" header type thingies to see if it can be reasonably added without breaking backwards compatibility with three decades of gopher clients though. That's where cat would start, anyway. Maybe it does exist!

@JTE oh shit sorry I was trying to reply to a thread and clicked on your (adjacent) toot by accident; I thought I'd corrected it but somehow still tagged you anyway?

(also, yeah, unfortunately it's a little out of scope for the protocol as it stands; in theory it'd be possible to add it but backwards compatibility is a fuck)

@aeonofdiscord Yeah. Unless you wanted to add a new item type for binary files that included a length number before sending the bytes. But I guess I'd still be fine with connections closing after binaries.
That final dot is still weird. And the need to dot-quote all other single dots because of it is also annoying.
And more, gopher clients like lynx will actually show you that final dot. What for?

@kensanata oh yeah, gopher+ allows you to specify a content length so if the client supports that then it might work

showing the final dot to the user is actually a bug, the RFC says you shouldn't do it. so why have it at all? 🤔

@kensanata that's no kind of excuse tbh. also what kind of person was still using ed in 1991

@feld @aeonofdiscord Well, I only discovered that a few weeks ago myself. 😂