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@gmail.com> wrote: > On Mon, 13 Dec 2021 11:21:44 +0000 > > Krixano krixano@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-gemi ni-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-gemi ni-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
---
Previous in thread (17 of 34): 🗣️ Krixano (krixano (a) protonmail.com)
Next in thread (19 of 34): 🗣️ Luke Emmet (luke (a) marmaladefoo.com)