💾 Archived View for rawtext.club › ~sloum › geminilist › 007698.gmi captured on 2024-03-21 at 15:39:50. 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 22:48:53 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Mon, 13 Dec 2021 20:38:12 +0000Krixano <krixano at protonmail.com> wrote:
And the argument that this cannot be desired in the spec because the
spec would explicitly state so is a non-argument.
I am not aware that anyone has made that argument. I certainly haven't.Perhaps you aren't reading my messages linearly and literally enough.
People can easily make mistakes or not think about how their words
might be against what they intended to say, which is why intention
behind words is more important then the actual words - and hence why
overly-literal interpretations are in fact *interpretations* and not
just reading what was written.
Yes, people can make mistakes. If such a mistake has happened here, ithas resulted in the specification (yes, not finalized) doesn'tpractically permit indefinitely streamed responses.
Again, I was never against making the spec more explicit and up to par
with what was intended. What I am for is not judging implementations
for using an intended design of the protocol (even if it's not in the
spec!) when a spec isn't even final yet.
It's the document we have as a basis for writing clients. If it'swrong, it's wrong. That can be fixed. But telling me that I should digthrough old gopher holes and mailing list archives just to get a senseof Solderpunk's general opinion on streaming request responses, andinterpret that opinion as a canonical part of the standard is not aviable basis for a standard.
-- 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/c3d3ac70/attachment.sig>