💾 Archived View for rawtext.club › ~sloum › geminilist › 001696.gmi captured on 2023-11-04 at 12:00:21. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
James Tomasino tomasino at lavabit.com
Mon Jun 15 13:39:03 BST 2020
- - - - - - - - - - - - - - - - - - -
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.
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.
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!