Hello and welcome!
On Fri, 2020-08-14 at 11:59 +0300, /dev/urandom wrote:
> 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.
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?
> 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.
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:
gemini://gemi.dev/gemini-mailing-list/messages/002269.gmi
"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."
> 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 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.
> 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.
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.
Cheers
Alex
---
Previous in thread (1 of 11): 🗣️ /dev/urandom (dev.urandom (a) posteo.org)
Next in thread (3 of 11): 🗣️ /dev/urandom (dev.urandom (a) posteo.org)