Krixano krixano at protonmail.com
Mon Dec 13 22:04:29 GMT 2021
- - - - - - - - - - - - - - - - - - -
Yes, you are right, actually, the Speculative Specification at the gemini homepage is the canonical one for the moment. The gitlab spec is for tracking changes to future versions of the spec.
What I'm frustrated with is that we have a bunch of evidence that shows that the intention has always been that clients could handle data before the close_notify, and yet people insist that this is not the case and that this is all just made-up crap being read into the spec. Intention behind what the spec says matters, because it's how we know whether the spec needs to be further clarified.This is why I think we should absolutely refrain from judging implementations that are not "spec-compliant" based on a non-finalized *speculative* specification. Experimentation early on in Gemini was appreciated because it allowed people to test out the protocol to see what could be done with it - this included a simple change to some clients that allowed for handling of data before close_notify. There is *no doubt* in my mind that allowing this was intended. Whether the specification allows for this is another matter that needs to then be clarified. Which is why I have created a GitLab Issue here: https://gitlab.com/gemini-specification/protocol/-/issues/44
Christian Seibold
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, December 13th, 2021 at 3:44 PM, romina xj ix k <gemini at xj-ix.luxe> wrote:
On December 13, 2021 9:38:04 PM UTC, Luke Emmet luke at marmaladefoo.com wrote:
On 13-Dec-2021 20:55, Krixano wrote:
that portion of text no longer even being present in the latest version of the spec on gitlab: https://gitlab.com/gemini-specification/protocol/-/blob/master/specification.gmi
Thanks for the link to the updated protocol, I was just going on the
version on the gemini home capsule as the official version.
Clearly whatever solderpunk puts in is what the spec is. And there is
less said now in the current draft of the spec about the expected
interleaving of client and server events. This leaves more room for
servers to expect clients to process the data before it is completed.
Still it seems unclear to me how a client can now tell between a faulty
or excessively slow server and one that is valid but is streaming
content very slowly. In the previous draft the expectation was the
client waits for content, which will conclude, then it is processed. Now
clients don't get to have a general expectation that the content will
conclude or not as it comes down the pipe.
Probably the best option is to try to guess whether the content might be
a stream from the media type as spc suggests, although that seems like
guesswork to me.
Anyway, clients and servers probably need to have a connection timeout
to prevent tar pits.
regards
- Luke
afaik the canonical spec lives on gemini.circumlunar.space not gitlab