gemini streaming

[Sean Conner]

It was thus said that the Great James Tomasino once stated:
> Since text/gemini (or gemtext, if that's what we're calling it) is
> parsable from top-to bottom in a single pass, it's also perfectly well
> suited to being treated as a stream instead of a document. I believe the
> only limitation to this currently is that many clients are expecting that
> gemtext is a document and are deferring parsing until the end-of-document
> is reached.
> 
> When I raised this question on the IRC channel I wanted to know if there
> was a way to indicate within the MIME perhaps that the resource is a
> stream and not a document. Then clients could know explicitly that they
> shouldn't be waiting on the end of document before parsing. I'm really not
> familiar with the technical mechanisms of how that's set up on HTTP, so I
> wanted to toss it to the list.

  A web browser already knows how it will deal with the content by the time
it's reading the body of the response, and unless the browser is going to
hand off the content to another program (say a PDF viewer) the browser can
just treat the resulting download of data as a stream.  TCP (the underlying
protocol for both HTTP and Gemini) provides a "reliable byte-oriented
stream" [1] and it's up to the client to deal with that as it sees fit.

  A Gemini client can see it's getting a text/gemimi file, and start reading
the network stream a line at a time and displaying it at the same time if it
so chooses.  It doesn't *have* to wait for the entire file to download
before processing it.

> Should we investigate a MIME solution to be explicit, or should clients
> treat all text/gemini as streams and just parse as they go? The later
> seems easier from a implementation standpoint. Someone raised the question
> about how the display should be handled between the two, though. Sometimes
> streams desire to keep the focus pinned to the newest content, not the
> start of the document. That sort of functionality would support using a
> separate explicit MIME or some other way to differentiate them.

  It depends how the client is written.  I client can certainly parse and
display a text/gemini as it receives it (much like web browsers can start
displaying partially downloaded content) but it complicates the codebase. 
Is it worth the tradeoff?  

> With streams in place we could do some very cool things. We could build a
> fediverse front-end, or a view into the IRC channel. If you use two tabs
> and a response 10 loop and client certs, you could even post INTO these
> platforms. Let your imagination run wild!

  Nothing stopping you now from doing that.  This no size parameter, a
Gemini client can continuously stream data to a client until the connection
is broken.

  -spc

[1]	Technically, TCP exists to manage the bandwidth between two
	endpoints, but it was engineers to also provide the said "reliable
	byte-oriented stream".  There are no packets to the client code,
	just a stream of bytes it has to read.