💾 Archived View for zaibatsu.circumlunar.space › ~solderpunk › gemini › spec-updates.txt captured on 2022-04-29 at 12:58:19.

View Raw

More Information

⬅️ Previous capture (2020-09-24)

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

Spec updates
------------

I've just updated the "speculative specification" document[1] 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.

[1] gopher://zaibatsu.circumlunar.space:70/0/~solderpunk/gemini/spec-spec.txt