💾 Archived View for rawtext.club › ~sloum › geminilist › 001724.gmi captured on 2020-09-24 at 01:41:23. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Sean Conner sean at conman.org
Tue Jun 16 02:18:22 BST 2020
- - - - - - - - - - - - - - - - - - -
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 timeit's reading the body of the response, and unless the browser is going tohand off the content to another program (say a PDF viewer) the browser canjust treat the resulting download of data as a stream. TCP (the underlyingprotocol for both HTTP and Gemini) provides a "reliable byte-orientedstream" [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 readingthe network stream a line at a time and displaying it at the same time if itso chooses. It doesn't *have* to wait for the entire file to downloadbefore 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 anddisplay a text/gemini as it receives it (much like web browsers can startdisplaying 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, aGemini client can continuously stream data to a client until the connectionis 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.