💾 Archived View for rawtext.club › ~sloum › geminilist › 002395.gmi captured on 2020-09-24 at 03:08:58. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Thoughts about the Gemini protocol

/dev/urandom dev.urandom at posteo.org

Fri Aug 14 12:18:04 BST 2020

- - - - - - - - - - - - - - - - - - -

On Fri, 14 Aug 2020 12:50:57 +0200Alex 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 inputwould still work in the exact same way. You get a basic string, entersomething, it gets added as a query, and the server returns either a2x or a 59. But the more advanced clients could provide analternate input method to make it easier for the user.

And, of course, repeating the mistakes of HTTP and HTML is something Iwant 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 othermechanism to allow for the user to read the already-loaded parts of apage 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-sidewhether 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 tostreaming. I was instead suggesting it as a way for applications tosend small messages in response to requests in a way that doesn'trequire 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