Krixano krixano at protonmail.com
Mon Dec 13 20:26:12 GMT 2021
- - - - - - - - - - - - - - - - - - -
The INTENDED SPEC is not the same as the ACTUAL SPEC! The intended spec matters because THE SPEC IS NOT FINAL.
Christian Seibold
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, December 13th, 2021 at 2:22 PM, Philip Linde <linde.philip at gmail.com> wrote:
On Mon, 13 Dec 2021 11:21:44 +0000
Krixano krixano at protonmail.com wrote:
Yeah, some people don't know Gemini History apparently, lol.
I do (being an avid phlog reader since long before Gemini) and I'm well
aware of the apparent controversy around streaming responses, but so
what if I didn't? Should implementors necessarily familiarize
themselves with the entire history of the protocol in order to be able
to implement it? Or fail and get laughed at because they "don't know
Gemini History apparently, lol"?
I imagine that if I actually was clueless about the history of Gemini
and came to this mailing list only to get laughed at because I didn't
read a bunch of phlogs where people vaguely promote an idea that isn't
allowed by the specification, I would think it patronizing, rude and
condescending, and would quickly leave what I'd assume was a bunch of
antisocial nerds to guard their lawn in peace.
People need to stop imposing their views on the standard as if it
part of the original design of the protocol when it wasn't.
Just to be clear, I'm reading the standard and interpreting it to my
best ability. This, in my view, exactly entails not reading things
into it, by reading it as literally as possible. This isn't just out
of an obstinate desire to cause a ruckus, but because that's how people
will read the specification when they don't have our contextual
baggage. Apparently in this case we've learned that the specification
doesn't reflect behavior which you seem to think is standard.
Regardless of whether that's a mistake in the spec or a
misinterpretation on your end, we can learn from that literal reading
what about the spec can be improved.
If from a description of a transaction as something that
ends with the server closing the connection followed by the client
handling the response I interpret it to mean exactly that, I don't
think that I am particularly imposing my views on the standard.
Solderpunk could change things at any time, of course, but that doesn't
change the original designs. So... No, as far as I'm aware, Gemini was
never about read-only. It was about balancing the power-to-weight
ratio. No, Gemini's text input was never exclusively for search -
there's an article written by Solderpunk that details why he included
input labels. No, Gemini was never anti-applications (at least since
the idea of Client Certificates). Solderpunk wrote an article showing
that applications were at least considered as a potential for the
protocol.
Completely beside the point. My criticism here has nothing to do with
the underlying principles of the design of the protocol, or the
intended use of certain features. My criticism is based on a reading of
the specification, and server behavior which apparently depends on
clients not following the specification according to this reading.
Also, no, having (text, and others) streaming and browsers
that interact with streams in Gemini is not against the intended spec.
So you say, but perhaps you have just imposed your own views on the
standard.
In fact, allowing for Text Streaming was a decision talked about
between Solderpunk, Tomasino (iirc), Mozz, and a few other people.
Solderpunk references this feature in one of his recent emails here on
the mailing list (regarding how close_notify doesn't affect streaming
via Gemini).
It was talked about between some people, and Solderpunk refers to it in
some recent email, yada yada. What use is this to someone reading the
specification? Is there a canonical amendment to the specification only
existing in the form of various phlog entries, gemlogs and emails?
Now, about what the spec states. If you read the spec too literally
and linearly, then I can kinda see how people might think the spec says
requests must be handled after close_notify, from:
What is the right degree of literality and linearity I should read the
specification with? Is it OK for example for the server to send the
response header after sending the response body? May the server
respond before CR+LF in the request line? What should I replace the
literal part of my reading with? My own views? The content of some
even relatively obscure phlog entry?
The point strikes me as rather absurd in the context of what you've
just said. On one hand you're asking people not to read things into the
standard. On the other hand, apparently my reading of the spec is too
literal.
I firmly believe that this is an undesired overly-linear
interpretation, and that perhaps Solderpunk might want to consider
changing this if necessary, and if his views on streaming haven't
changed. Remember, the spec isn't actually final yet.
That may very well be true, in which case I agree that the
specification should be updated. But it clearly isn't the behavior the
specification currently specifies.
As for the links:
On Inputs and Client Certificates: gopher://zaibatsu.circumlunar.space:70/0/~solderpunk/gemini/inputs-and-client-certs.txt
On Streaming (Tomasino): gemini://rawtext.club/~sloum/geminilist/001696.gmi
On Applications and Streaming (Solderpunk): gemini://gemini.circumlunar.space/users/solderpunk/gemlog/a-vision-for-gemini-applications.gmi
Mozz's Response to Solderpunk on Streaming: gemini://mozz.us/journal/2020-06-21.gmi
Links via Gemini:
On Inputs and Client Certificates: gemini://zaibatsu.circumlunar.space/~solderpunk/gemini/inputs-and-client-certs.txt
On Streaming (Tomasino): [Only Available Via Gopher, afaik]
On Applications and Streaming (Solderpunk): gemini://gemini.circumlunar.space/users/solderpunk/gemlog/a-vision-for-gemini-applications.gmi
Mozz's Response to Solderpunk on Streaming: [Only Available Via Gopher, afaik]
Hey, don't forget that email you vaguely referred to that Solderpunk
sent to the list recently! Jokes aside, this is another great example
of why I think de facto standards are a bad idea. Clearly, it would be
advantageous for an implementor to be able to read from the
specification that it was indeed intended for clients to handle
streaming responses. Then you don't need what increasingly will
resemble case law to determine whether your implementation is correct.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Philip