Proposal: Simple structured form specification

Russtopia rmagee at gmail.com
Tue Jan 26 19:25:32 GMT 2021


On Tue, 26 Jan 2021 at 05:43, Jason McBrayer <jmcbray at carcosa.net> wrote:

> nothien at uber.space writes:
> > Russtopia <rmagee at gmail.com> wrote:
> >> [... form proposal ... ]
>
> > The issue is that Gemini (and gemtext) is too close to being frozen
> > forever. And most Gemini content out there doesn't need to use forms.
>
> This is my personal opinion, but I would go further and say that Gemini
> doesn't need forms. If you have fully featured forms, you can implement
> largely any kind of application (excluding very interactive ones), and
> in the history of the web, this lead to re-implementing the whole
> internet over port 80. I don't think Gemini needs to do that. The one
> input lets you select different dynamic versions of a page, like for
> different locales, or search results, or similar.
>
> Having more complex forms is a temptation to implement applications on
> Gemini, rather than using pairings of protocol+client that are more
> appropriate (e.g. using NNTP for a message board).
>
>
Point well taken -- I know it is a slippery slope, but I still think forms
could be
supported in a manner which keeps complexity down.

This form-builder idea could be implemented with no protocol changes,
100% client-side, within the existing => link syntax. To be user-friendly,
it would
require some sort of agreement by clients on the FORM-SPEC syntax.
Consider if clients agreed to act on documents ending in .gmif
('gemini-form'):

=> gemini://example.site/form.gmif This is a form link, click to fill out

.. clients could, by convention, parse such .gmiform files containing the
FORM-SPEC
using it to build a dynamic entry form. After form entry, the client would
encode it and send back
to the same endpoint (here, form.gmif) so the server could act on the
values.

For clients that did not choose to implement forms, they would by default
simply display .gmif
documents as any other plaintext resource.

The .gmif document holding the <FORM-SPEC> could even have comments with
instructions
on how to manually create a query to the endpoint, for users of older
clients eg:

[form.gmif]

s#DELAY#5#Delay in seconds
> c#SIZE#small|big|huge#Size of something
> b#DEBUG#1#
>
> // If you are seeing this page, your gemini client does not support
> automatic dynamic forms.
> // You can still use this service by building a FORM-SPEC matching the
> above syntax and
> // pasting it to this page's URI, eg:


> //    gemini://example.site/form.gmif?DELAY=5&SIZE=small&DEBUG=1



As ~nothien points out, there's a limit of ~1024 bytes on URLs which I
think is a good thing;
working within the protocol as-is will naturally force relatively small,
simple forms.

So I guess I'm now proposing an optional client-side '.gmif' form standard
:)

-Russ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210126/f34c1343/attachment.htm>


More information about the Gemini mailing list