<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 26 Jan 2021 at 05:43, Jason McBrayer <<a href="mailto:jmcbray@carcosa.net" target="_blank">jmcbray@carcosa.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><a href="mailto:nothien@uber.space" target="_blank">nothien@uber.space</a> writes:<br>
> Russtopia <<a href="mailto:rmagee@gmail.com" target="_blank">rmagee@gmail.com</a>> wrote:<br>
>> [... form proposal ... ]<br>
<br>
> The issue is that Gemini (and gemtext) is too close to being frozen<br>
> forever. And most Gemini content out there doesn't need to use forms.<br>
<br>
This is my personal opinion, but I would go further and say that Gemini<br>
doesn't need forms. If you have fully featured forms, you can implement<br>
largely any kind of application (excluding very interactive ones), and<br>
in the history of the web, this lead to re-implementing the whole<br>
internet over port 80. I don't think Gemini needs to do that. The one<br>
input lets you select different dynamic versions of a page, like for<br>
different locales, or search results, or similar.<br>
<br>
Having more complex forms is a temptation to implement applications on<br>
Gemini, rather than using pairings of protocol+client that are more<br>
appropriate (e.g. using NNTP for a message board).<br>
<br></blockquote><div><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Point well taken -- I know it is a slippery slope, but I still think forms could be</div><div class="gmail_default" style="font-family:verdana,sans-serif">supported in a manner which keeps complexity down.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">This form-builder idea could be implemented with no protocol changes,</div><div class="gmail_default" style="font-family:verdana,sans-serif">100% client-side, within the existing => link syntax. To be user-friendly, it would</div><div class="gmail_default" style="font-family:verdana,sans-serif">require some sort of agreement by clients on the FORM-SPEC syntax.</div><div class="gmail_default" style="font-family:verdana,sans-serif">Consider if clients agreed to act on documents ending in .gmif ('gemini-form'):</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">=> gemini://example.site/form.gmif This is a form link, click to fill out</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">.. clients could, by convention, parse such .gmiform files containing the FORM-SPEC</div><div class="gmail_default" style="font-family:verdana,sans-serif">using it to build a dynamic entry form. After form entry, the client would encode it and send back</div><div class="gmail_default" style="font-family:verdana,sans-serif">to the same endpoint (here, form.gmif) so the server could act on the values.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">For clients that did not choose to implement forms, they would by default simply display .gmif</div><div class="gmail_default" style="font-family:verdana,sans-serif">documents as any other plaintext resource.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">The .gmif document holding the <FORM-SPEC> could even have comments with instructions</div><div class="gmail_default" style="font-family:verdana,sans-serif">on how to manually create a query to the endpoint, for users of older clients eg:</div><div class="gmail_quote"><br></div><div class="gmail_quote"><div class="gmail_default" style="font-family:verdana,sans-serif">[form.gmif]</div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">s#DELAY#5#Delay in seconds<br>c#SIZE#small|big|huge#Size of something<br>b#DEBUG#1#<br> <br>// If you are seeing this page, your gemini client does not support automatic dynamic forms.<br>// You can still use this service by building a FORM-SPEC matching the above syntax and<br><span class="gmail_default" style="font-family:verdana,sans-serif">// pasting it to this page's URI, eg:</span><span class="gmail_default" style="font-family:verdana,sans-serif"></span></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail_default" style="font-family:verdana,sans-serif"><br></span>// ¬† ¬†gemini://example.site/<span class="gmail_default" style="font-family:verdana,sans-serif">form.gmif?</span>DELAY=5&SIZE=small&DEBUG=1</blockquote></div><span class="gmail_default" style="font-family:verdana,sans-serif"><div class="gmail_default"></div></span><div><div class="gmail_quote"><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><div class="gmail_default">As ~nothien points out, there's a limit of ~1024 bytes on URLs which I think is a good thing;</div><div class="gmail_default">working within the protocol as-is will naturally force relatively small, simple forms.</div><div class="gmail_default"><br></div><div class="gmail_default">So I guess I'm now proposing an optional client-side '.gmif' form standard :)</div><div class="gmail_default"><br></div><div class="gmail_default">-Russ<br></div></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"></div></div></div></div>