💾 Archived View for rawtext.club › ~sloum › geminilist › 007687.gmi captured on 2023-12-28 at 15:53:20. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-09-08)
-=-=-=-=-=-=-
Philip Linde linde.philip at gmail.com
Mon Dec 13 20:22:25 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Mon, 13 Dec 2021 11:21:44 +0000Krixano <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 wellaware of the apparent controversy around streaming responses, but sowhat if I didn't? Should implementors necessarily familiarizethemselves with the entire history of the protocol in order to be ableto implement it? Or fail and get laughed at because they "don't knowGemini History apparently, lol"?
I imagine that if I actually was clueless about the history of Geminiand came to this mailing list only to get laughed at because I didn'tread a bunch of phlogs where people vaguely promote an idea that isn'tallowed by the specification, I would think it patronizing, rude andcondescending, and would quickly leave what I'd assume was a bunch ofantisocial 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 mybest ability. This, in my view, exactly entails not reading thingsinto it, by reading it as literally as possible. This isn't just outof an obstinate desire to cause a ruckus, but because that's how peoplewill read the specification when they don't have our contextualbaggage. Apparently in this case we've learned that the specificationdoesn't reflect behavior which you seem to think is standard.Regardless of whether that's a mistake in the spec or amisinterpretation on your end, we can learn from that literal readingwhat about the spec can be improved.
If from a description of a transaction as something thatends with the server closing the connection followed by the clienthandling the response I interpret it to mean exactly that, I don'tthink 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 withthe underlying principles of the design of the protocol, or theintended use of certain features. My criticism is based on a reading ofthe specification, and server behavior which apparently depends onclients 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 thestandard.
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 insome recent email, yada yada. What use is this to someone reading thespecification? Is there a canonical amendment to the specification onlyexisting 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 thespecification with? Is it OK for example for the server to send theresponse header after sending the response body? May the serverrespond before CR+LF in the request line? What should I replace theliteral part of my reading with? My own views? The content of someeven relatively obscure phlog entry?
The point strikes me as rather absurd in the context of what you'vejust said. On one hand you're asking people not to read things into thestandard. On the other hand, apparently my reading of the spec is tooliteral.
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 thespecification should be updated. But it clearly isn't the behavior thespecification 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 Solderpunksent to the list recently! Jokes aside, this is another great exampleof why I think de facto standards are a bad idea. Clearly, it would beadvantageous for an implementor to be able to read from thespecification that it was indeed intended for clients to handlestreaming responses. Then you don't need what increasingly willresemble case law to determine whether your implementation is correct.
-- Philip-------------- next part --------------A non-text attachment was scrubbed...Name: not availableType: application/pgp-signatureSize: 488 bytesDesc: not availableURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20211213/486c5834/attachment.sig>