Thoughts about the Gemini protocol

[/dev/urandom]

Hello everyone,

The recent news about the layoffs at Mozilla have left me wondering as 
to whether the modern web has become too complex. I've heard people 
discuss the Gemini protocol as a simplified alternative that is way 
easier to work with. After checking it out (and even trying to write a 
small experimental client in C, which thanks to libtls, ended up way 
easier than I thought), it seems to be a really promising idea.

I was thinking about an idea similar to Gemini that could work as a 
protocol for not just websites, but also simple and functional web 
applications as well that could, to a reasonable extent, look and work 
well on lots of different devices (desktops, smartphones, feature 
phones, text-mode interfaces). After seeing how the Gemini protocol 
works, it seems to me that a lot of these ideas could be implemented in 
a backwards-compatible way or with minimal modifications to the 
protocol.

1. Basic form inputs / "widgets"

In addition to an "INPUT" response that only requests a line of text and 
returns the question as a single line in the <META> field, some sort of 
"extended input" could be useful. It could still be restricted to a 
single query, but it could provide software-interpretable hints as to 
what kind of input is preferable.

For example, a "check" input could provide a numbered list of options 
and then ask the user to submit a query consisting a list of the 
numbered items the user wants to select (or 0 if none). A more advanced 
client program would then display the entire request as a series of 
checkboxes or switches that the user can toggle. A "radio" or "button" 
input could demand a single number, and the client would display the 
items as a list of radio switches or buttons, of which only one can be 
selected.

(I can imagine the description of the inputs either being part of the 
<META> field, part of the previous page's text or maybe an "extended 
input" could have its own response body that they're written in.)

Or a "date" input could say that it expects a date in the YYYY-MM-DD 
format, but an advanced client could provide the user with a date picker 
instead.

Either way, the general idea is that a simple client could just ask the 
user to write the query as a line of text.

2. Continuous connections

A user might want to not just give commands to a service, but also to 
expect it to provide a continuous stream of information over a long 
term. Most modern web pages use scripting to accomplish something like 
that (and most web-browsers wait for a page to finish loading before 
displaying it), but a minimal version of this seems achievable without 
it.

An additional response type (say, "21 SUCCESS WITH CONTINUOUS RESPONSE") 
or mime-type (say, "text/gemini-continuous") would indicate that the 
server will not give the entire response at once and then immediately 
close the connection, but instead the connection will continue for a 
long time, and instead of waiting for the entire text to be received, 
the client should look for whenever a complete line arrives and print 
that line.

The client could then use that connection to receive updates on the 
request, until either the client or the server actually decides to close 
the connection or it gets closed by some other means.

3. Append mode

This is just a little extra feature, but the idea is that a page 
(probably also via mime-type, like "text/gemini-append", or an 
additional parameter, like "text/gemini; append") could indicate that 
its contents should, if possible, be added at the end of the previous 
page, rather than replacing it entirely.

---

I would like to hear your opinions as to whether these ideas could, or 
should, be added to the Gemini protocol, and in which specific ways if 
so. Thank you all very much.