💾 Archived View for gemi.dev › gemini-mailing-list › 000738.gmi captured on 2023-11-04 at 13:04:37. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Hi, as I understand it, currently only prompts for single-line inputs are supported, and it seems this is mostly intended for queries to search engines. This means, a (anonymous) commenting system could not be implemented on a gemini page (except for one-line comments). If multiline input prompts were possible, then you could implement a commenting system like this: the user would click on a "Click to add comment" link and then would get a text prompt where she could input a comment and then submit. (Optionally, the text prompt could be edited in an external editor.) I understand that the protocol explicitly doesn't want to implement complicated mechanisms like POST, but maybe it's possible to escape the line breaks and submit a multiline input the same way a single-line input can be submitted right now? (While I'm thinking about this, it might also be nice to let the server specify a MIME type for the input.) This system would still be far from the complexity of HTML forms (essentially it's equivalent to only allowing a single <textarea>), but might already be quite useful. Best, Thomas
> On Feb 22, 2021, at 13:35, Thomas M <thomas5max at gmail.com> wrote: > > (While I'm thinking about this, it > might also be nice to let the server specify a MIME type for the input.) Yes, but... there is a hard limit of 1024 bytes per requests, in the specification. One could always introduce continuation or such, but this is crossing into Rube Goldberg territory. ?0?
> On Feb 22, 2021, at 13:35, Thomas M <thomas5max at gmail.com> wrote: > > I understand that the protocol explicitly doesn't want to implement > complicated mechanisms like POST One way to deal with the 1024 bytes per request limit, would be to submit an URL to the server. Then the server retrieve the content. Rube Goldberg again. ?0?
Thomas M <thomas5max at gmail.com> writes: > Hi, > > as I understand it, currently only prompts for single-line inputs are > supported, and it seems this is mostly intended for queries to search > engines. This means, a (anonymous) commenting system could not be > implemented on a gemini page (except for one-line comments). > > If multiline input prompts were possible, then you could implement a > commenting system like this: the user would click on a "Click to add > comment" link and then would get a text prompt where she could input a > comment and then submit. (Optionally, the text prompt could be edited in > an external editor.) > > I understand that the protocol explicitly doesn't want to implement > complicated mechanisms like POST, but maybe it's possible to escape the > line breaks and submit a multiline input the same way a single-line > input can be submitted right now? (While I'm thinking about this, it > might also be nice to let the server specify a MIME type for the input.) > > This system would still be far from the complexity of HTML forms > (essentially it's equivalent to only allowing a single <textarea>), but > might already be quite useful. > > Best, > Thomas Nothing prevents an user to submit a multi line replies to a 10/11 input (UIs aside.) I just tested this on elpher: `C-q C-j' inserts a newline and it gets serialised ad %0A (as it should) when building the query. The 1K limit still applies tho
"Thomas M" <thomas5max at gmail.com> writes:
> Hi,
>
> as I understand it, currently only prompts for single-line inputs are
> supported, and it seems this is mostly intended for queries to search
> engines. This means, a (anonymous) commenting system could not be
> implemented on a gemini page (except for one-line comments).
I had the same limitation when creating DNA (gemini://nixo.xyz), but
managing continuation on the server works quite well. But I need "user
info" (a certificate) to link different requests together. This could
also be achieved by using an UUID in the uri. The server waits for a
specific message ('!save' in my case, but could also be the empty
message) to be inserted in order to know when to save the message.
---