Documents with mixed languages

[Philip Linde]

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-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