On Sat, 18 Jul 2020 23:05:21 +0100 Luke Emmet <luke at marmaladefoo.com> wrote: > > I would be against this - it would be a radical change from the existing > spec - section 1.1 says that the server closes the connection. At > present we have a simple model - client request-> server response and > close. Would it be an optional status code that some clients accept and > others reject (in which case it would seem to violate that you can just > check the first digit of the status). I agree that this is a radical change. I think other protocols largely cover potential use cases for indefinite text/gemini responses, and Gemini can by design concede such functionality to other software via e.g. ircs/ssh URLs instead of creating an additional burden on Gemini client implementations. A quite opposite change I'd much rather see, however radical, is some kind of required content length indicator in the header, but I'm also willing to hear what use cases people are envisioning for streaming responses. There has been talk about whether it can be done, and AFAIK a sort of half-IRC to demonstrate that it indeed works in some clients as a side effect of their design, but I haven't heard of a really compelling use case yet. -- Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200731/90f5 9c9b/attachment.sig>
---
Previous in thread (7 of 12): 🗣️ colecmac (a) protonmail.com (colecmac (a) protonmail.com)
Next in thread (9 of 12): 🗣️ Katarina Eriksson (gmym (a) coopdot.com)