💾 Archived View for rawtext.club › ~sloum › geminilist › 004932.gmi captured on 2023-09-28 at 17:22:38. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
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 formscould besupported 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 wouldrequire 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 theFORM-SPECusing it to build a dynamic entry form. After form entry, the client wouldencode it and send backto the same endpoint (here, form.gmif) so the server could act on thevalues.
For clients that did not choose to implement forms, they would by defaultsimply display .gmifdocuments as any other plaintext resource.
The .gmif document holding the <FORM-SPEC> could even have comments withinstructionson how to manually create a query to the endpoint, for users of olderclients 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 Ithink 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>