💾 Archived View for rawtext.club › ~sloum › geminilist › 007700.gmi captured on 2023-11-04 at 12:09:46. Gemini links have been rewritten to link to archived content

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

Documents with mixed languages

Krixano krixano at protonmail.com

Mon Dec 13 23:49:22 GMT 2021

- - - - - - - - - - - - - - - - - - -

If I could feed into a machine the fact that Solderpunk thinks

streaming response experiments are cool and interesting, and get an

unambiguously correct implementation out of it, I would, but I can't.

You can, it's called programming. The "unabiguously correct implementation" is to start handling the data the moment is gets to the client. Again, you're trying to overcomplicate this to make your point look better, when it's literally not. The most obvious thing to do would be to handle the data as it comes in. That's the natural thing to do, it's what most things do, and it's what most users expect, and it doesn't involve any ambiguity or breaking changes to capsules that don't use streaming (because the disconnect is happening in the opposite direction, when a client doesn't handle data as it comes in when the server might want it to).

It's my opinion that if someone who has never visited the mailing

list and who doesn't keep tabs on Solderpunk's other writing takes the

specification and implements it exactly as written, they're correct. If

their software then doesn't interoperate with other software

implementing the protocol, either the other software or the

specification is incorrect.

This is not what you originally said, fyi.

Whether I, personally, can read it and consider its content with the

context of having followed the mailing list or having followed some

phlogs early on is irrelevant. My point is that no one who wants to

implement the protocol should have to waste that time to achieve

interoperability.

Nobody said otherwise. What you shouldn't do is act like clients that allow for streaming are somehow ruining Gemini by adhering to the intended designs of the protocol, or even by adhering to the latest non-official specification of the protocol even if it conflicts with the official speculative specification. This isn't a 'tyranny of a multitude of "loud minorities"'.

The ideal outcome of a formal, canonical standard is

that an implementor should not have to go spelunking and survey existing

implementation (or indeed this mailing list) to learn what feature set

a client or a server is currently expected to implement not to be

effectively broken.

And in my opinion, this should only apply to finalized specifications. Why? Because a non-finalized specifications might desire things that haven't been added or fixed in the formal specification, and it's useful to not have the ecosystem be all over the place when the protocol is still growing or finalizing. Do you think there was a fully written out spec before the first Gemini servers were created? Of course not, because doing so would have been disastrous - there would have been no testing done whatsoever, so the spec would be just a bunch of theoretical crap with no real-world experience behind it.

Christian Seibold