On the shortcomings of gemini protocol
Marek, a fried who is a scientist, has this to say about gemini:
Not allowing images is not great, because in technical reports/science/...
we still need diagrams, plots, ...
But def there should be a requirement that all images must be relevant to the text; not like some generic random meaningless stock photos
Plus I don't think Gemini supports tables? They're important too
FWIW, images are supported. They are not rendered by default, you have to click on them and then it does render them (if the browser can, that is; there are terminal-based ones; though even terminals can display images nowadays! even xterm, which I use!).
But there's one criticism I've seen that might be more damaging:
I don't believe Gemini has a marker to distinguish the end of a file, which is good because I imagine theoretically any document can contain such a marker. However, what it also doesn't have is a way to say when the file has ended.
If you don't implement heartbeats in your connection (which is also not a reliable indicator that the server is done sending the file -- see streamed generated bodies) then AFAICT there's no way to tell that the server is done sending the file."
-- ryansquared, a 'friend' from Matrix
This is harder to solve. And they are probably adamant about not adding stuff to the protocol, in fear it will grow features and make server and client implementation harder.
Simplicity is valuable.
In a way gemini: is saying "we fucked up the web big time and now we all rely on a big piece of code we don't control -chrome-) for all our interactions: we can do better." Part of doing better implies to close down the design so that there's no future feature added that could take in the direction we are now with the web:
As per LWN:
“Another interesting piece of the protocol is that it is explicitly designed to be non-extensible. There is no version number in the protocol, and the response layout was carefully constructed to make extending it hard:
To minimise the risk of Gemini slowly mutating into something more web-like, it was decided to [include] one and exactly one piece of information in the response header for successful requests. Including two pieces of information with a specified delimiter would provide a very obvious path for later adding a third piece - just use the same delimiter again. There is basically no stable position between one piece of information and arbitrarily many pieces of information, so Gemini sticks hard to the former option, even if it means having to sacrifice some nice and seemingly harmless functionality”
Comments on HN: