Thoughts about the Gemini protocol

[/dev/urandom]

On Fri, 14 Aug 2020 12:50:57 +0200
Alex Schroeder <alex at gnu.org> wrote:

> It's interesting... but also a bit of a feature creep. My suspicion
> would be that all of this could be handled by simple string input and
> validation (your age, your zip code, your preferred choice from a
> menu), or by using links to provide alternatives... I do wonder what
> you have in mind though. I'd say if the goal is to write web apps,
> perhaps Gemini is not the right way to do it. And every extension makes
> it a bit more complicated and at the end people can't implement it in a
> day. We'd be repeating all the iterations of HTTP and HTML, no?

I understand. My intention was that, for a basic client, the input
would still work in the exact same way. You get a basic string, enter
something, it gets added as a query, and the server returns either a
2x or a 59. But the more advanced clients could provide an
alternate input method to make it easier for the user.

And, of course, repeating the mistakes of HTTP and HTML is something I
want to avoid as much as you.

> I think you'll find a discussion of this in the archives. Look for the
> thread "Reopening: Stream status code". I think the key message is this
> one:
> https://lists.orbitalfox.eu/archives/gemini/2020/002269.html
> "This is mainly just an issue of what to do about timeouts, right? If
> you don't have any timeout at all, streamed content works fine, but
> buggy/overloaded servers hang the client, and that's bad.  If you have
> a fixed timeout of 5 seconds, some streaming applications (like the
> chat example mozz has done) break."

I guess that ideally, any client would use threads or some other
mechanism to allow for the user to read the already-loaded parts of a
page while it's being loaded, while indicating that the page is
"incomplete" in some way in the user interface.

Then it wouldn't be necessary to specifically signal server-side
whether or not the page is streamed or loaded as a single piece.

> I think if you read the discussions regarding streaming, you'll see
> that if the server doesn't hang up, and if clients don't implement
> timeouts, all of this naturally just happens.

The third suggestion (appendable pages) was actually unrelated to
streaming. I was instead suggesting it as a way for applications to
send small messages in response to requests in a way that doesn't
require the server to re-send the original page every time.

> Sorry to be a cold blanket here, but my answer is No to all of the
> ideas. Instead, with respect to your ideas, let's focus on these two
> points:
> 
> 1. Clients without timeouts with an appropriate UI to help users
> interpret what they are seeing.
> 
> 2. Websites ("applications") with appropriate user interfaces such that
> we don't need structured input.
> 
> I think it's doable, but it isn't as simple as it seems at first sight.

It's all okay. I understand and appreciate your responses anyway.

> Cheers
> Alex

Thanks!
~ /dev/urandom