gemini+stream://

[James Tomasino]

On 8/15/20 6:41 PM, cage wrote:
> OK, my honest question  is now is: "is the last  point true?".  Let me
> give you an example (sorry i have to talk about my work, i hope you do
> not feel this annoying).

This was the original point I missed as well when I first started talking about streaming in Gemini. According to the specification section 1.1, here's the transaction summary:

C:   Opens connection
S:   Accepts connection
C/S: Complete TLS handshake (see section 4)
C:   Validates server certificate (see 4.2)
C:   Sends request (one CRLF terminated line) (see section 2)
S:   Sends response header (one CRLF terminated line), closes connection
     under non-success conditions (see 3.1 and 3.2)
S:   Sends response body (text or binary data) (see 3.3)
S:   Closes connection
C:   Handles response (see 3.4)

Notice that final "Closes connection" before "Handles response". If that were reversed then the protocol would effectively assume everything was a stream and everyone's clients would be built in the manner you've been working toward. Since it's explicit that the connection closes first in the spec it's understandable that client authors built clients the way they have.

Your technique of treating everything as a stream may "just work" for gemini:// and gemini+stream:// both, honestly. Time will tell!