💾 Archived View for geminiprotocol.net › history › phlog › spec-updates.gmi captured on 2023-09-08 at 16:04:04. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Spec updates

(originally posted in Gopherspace on 2019-08-11)

I've just updated the "speculative specification" document fairly extensively. Anybody who has implemented a publically available Gemini server or client is urged to read the latest spec-spec and make changes as required. I will be doing so for all of my software in the coming days. Because there has been a change to the request format this will probably throw us into a short period of incompatibility as everybody gradually gets their code onto the same page over time, but hopefully it will be a short period and hopefully it will be the last time anything like this happens for quite a while.

Along with tightening up various details which have been left vague or implicit until now, the most significant changes are:

The request format has changed to spec sending a URL rather than just a path to the server, as described in my last post. This will allow virtual hosting and proxying, including protocol-converting gateways which I, for one, am pretty excited about.
The two-digit status codes in response headers are now finally defined so we can get this important part of things standardised at last.
The spec now says explicitly that clients don't need to, but if they want to may choose to reflow text so that lines break at the appropriate points for narrow displays.

This is more or less the point I had really hoped to be at by the end of July, so we're a little behind schedule, but oh well. Now all the over-the-wire details, or at least the major ones, are defined and I consider them pretty well locked-in. I'm not guaranteeing nothing more will change, but I'm pretty darn happy with how things look right now and I want further changes to be very well motivated, as small as possible and hopefully backward compatible.

At this point, the features defined in the spec are quite far in front of what anybody has actually implemented in software yet. I don't think that's a good thing and I'd like us to focus on closing that gap instead of thinking about further changes. Additional changes to the spec (of the small and compatible kind) should ideally be motivated by us observing actual practical problems with actual working implementations instead of designing from our armchairs.

I'd like to say a big thanks to everybody who has offered any comments or suggestions on Gemini up to this point. The protocol as it is specced today is quite different from how I'm sure it would have ended up if I'd designed it quietly, entirely on my own, and I think it's better for that. I think we're going to end up with something really cool.