💾 Archived View for rawtext.club › ~sloum › geminilist › 002359.gmi captured on 2020-09-24 at 01:15:31. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Philip Linde linde.philip at gmail.com
Fri Jul 31 09:30:36 BST 2020
- - - - - - - - - - - - - - - - - - -
On Sat, 18 Jul 2020 23:05:21 +0100Luke 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 largelycover potential use cases for indefinite text/gemini responses, andGemini can by design concede such functionality to other software viae.g. ircs/ssh URLs instead of creating an additional burden on Geminiclient implementations.
A quite opposite change I'd much rather see, however radical, is somekind of required content length indicator in the header, but I'm alsowilling to hear what use cases people are envisioning for streamingresponses. There has been talk about whether it can be done, and AFAIKa sort of half-IRC to demonstrate that it indeed works in some clientsas a side effect of their design, but I haven't heard of a reallycompelling use case yet.
-- 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/20200731/90f59c9b/attachment.sig>