makew0rld
Support streams
An example page with a stream URL is gemini://chat.mozz.us, with the actual stream at gemini://chat.mozz.us/stream.
Even for plaintext streams like the one above, this would require a major architectural change, since Pages are designed to hold their entire content in a string. ~~A work around could be a stream mode, which might be hard/annoying to get the user to choose though. Could be a shortcut, so they select a link and then press Ctrl-S, or maybe it could be dynamically determined once content reaches a certain length, or the connection doesn't close?~~
Edit: I no longer consider stream mode to be a viable solution. Large non-stream pages would also benefit from Amfora moving to a stream-based architecture.
Hopefully a status code for a stream will be added.
Edit: This will not be happening.
The rendering functions should already work well with partial content, maybe only passing parts of content can be the default mode, updating the Page each time? The only state that would need to be passed each call would be whether it's in a preformatted mode or not, which could be added to Page or something.
~~Stream support will require the ability to load URLs and setpages even when another tab is selected. This means the tab number should be passed to funcs like handleURL and setPage, so they don't just use curTab.~~ There will also have to be a way to stop the loading when the tab is closed.
Edit: The first part of this is completed.
As of 7fe78f4d6bb3222640ac8c7792e29a5235aee60d there is now a configurable download timeout on pages. This would need to be disabled for streams.
There could be a render and page display pipeline that implements io.Writer, so network input can be written directly and displayed live.
~~Using the protocol gemini+stream:// has been proposed.~~ It is no longer encouraged or "required", see here.
The default 2 MiB page limit can be upped or page limits can be removed entirely once this is implemented.
Edit: Maybe just upped instead of removed, so that infinite or gigantic pages don't take up too much memory
Once this feature is added the info bar (#142) code will have to be modified so that the total page lines and page percentage changes on the fly.
There should be a line-based parser that implements io.ReadWriter. Each tab will have a parser and also be refactored to hold the network connection. Page can be changed so that Raw and Content are bytes.Buffer. To load a page, the tab will copy the incoming network bytes to Raw and to the parser, and then copy the parser output to Content and the TextView of the tab. When loading a new page, the parser will be scrapped and recreated, and the old network connection closed.
The parser will also have a links channel (buffered), which the tab can pull from to fill the Links slice of the Page. Page will probably need a mutex, in case the user is tabbing around the links while the page is loading.
Moving this to v1.10.0. It has been slowing down the release of v1.9.0 for much too long. There are more important updates that are already in master but are unreleased, or still need to be added. This would be great to have but is not really important from a user's point of view.