[spec] The Tragedy of &
cowan at ccil.org
Sun Jan 31 03:09:55 GMT 2021
On Wed, Jan 27, 2021 at 5:20 PM Gary Johnson <lambdatronic at disroot.org>
> I don't think form-like data submission should be seen as an evil. It
> allows us to implement a wide variety of CGI-style applications that do
> all their computing on the server side (often through some script
> extension mechanism).
which $SESSION, $NAME, $PASSWORD, $SMOG, and $PLANT are defined (or default
> to empty strings). When the page first loads, we create a new
> $SESSION value in our CGI script and insert it into the links to
> preserve state across requests until we restart the server or the user
> refreshes the page.
I think this is exactly the Right Thing.
> (Obviously, a more robust state management mechanism could be achieved
> with client certs and a DB, but I just mean to show a very simple
> example here.)
A TLS session is not the same as an application session. I may, for
example, have two tabs (or whatever) open in my Gemini browser that refer
to the same access-controlled capsule, and which therefore must be accessed
with the same cert. Nevertheless, the two pages should operate as distinct
sessions: I should be able to fill out a form in one page while searching
help documents in the other. So I think a session ID is the Right Thing.
However, this is a matter of server/capsule/CGI design, not of the Gemini
While this example creates more back-and-forth requests than a proper
client-side form would generate, I hope it demonstrates that Gemini and
> Gemtext in their current incarnations are already sufficiently complete
> to build interactive CGI applications with them today.
The biggest problem is most likely the cost of setting up and tearing down
all the TLS connections, but there is no help for that.
> The requested resource accepts a line of textual user input. The <META>
> line is a prompt which should be displayed to the user. The same
> resource should then be requested again with the user's input included
> as a query component.
"Included" is a vague word, and should be fixed whether we do appending or
> As far as I can tell, the fix here is for Solderpunk to update the text
> in section 3.2.1 to indicate that if a query string is already part of
> the request leading to an INPUT response, then the user's input should
> be appended (using &) to the existing query string rather than replacing
> it wholesale (using ?).
I suggest that if there is no query part, we append ? followed by the
user's input, whereas if there is, we just append the user's input. That
lets a simple form work like this:
1) Suppose Fluffy (a server) wants me to send my name and email address.
Fluffy sends this bare-bones text/gemini document, which we will say comes
from gemini://fluffy.example/form1, to my client Aarfy.
=> Name: ?name=
=> Email: ?email=
2) Let's say I choose the first link. Fluffy sends Arfy 10 Enter your name.
I type John Cowan into Aarfy, which sends the URL
gemini://fluffy.example/form1?session=ABC&name=John%20Cowan. Fluffy sends
this new document to Aarfy:
=> Name [John Cowan]: ?session=ABC&name=
=> Email: ?session=ABC&name=John%20Cowan&email=
3) If I choose the first link, I can change my name. If I choose the
second link, Fluffy will send Arfy 10 Enter your email. I type
cowan at ccil.org into Aarfy, which sends the URL
cowan at ccil.org. Fluffy sends this third document to Aarfy:
=> Name [John Cowan]: ?session=ABC&email=cowan at ccil.org&name=
=> Email: [cowan at ccil.org] ?session=ABC&name=John%20Cowan&email=
=> Submit: [cowan at ccil.org] ?session=ABC&name=John%20Cowan&email=
cowan at ccil.org&submit
4) If I choose the first or second link again, I can change my name or
email address. But if I choose the third link, which Fluffy does *not*
interpret as a search link, Fluffy will write my name and email into a
database, or send me an email saying "HA HA HA!", or whatever it does.
Because all that happens is following links and reading input lines, it
does not matter if Aarfy is a CLI, TUI, or GUI client: the protocol
exchanges work in any case. Furthermore, Fluffy does not have to retain
partial state, because it is passed back and forth between Aarfy and Fluffy
with no real interpretation at either end until Aarfy receives a submission
For that matter there is no real need to have a submission link: an URL
that specifies both name and email could be interpreted as a submission.
As before, this is a matter of design, not protocol.
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
There is no real going back. Though I may come to the Shire, it will
not seem the same; for I shall not be the same. I am wounded with
knife, sting, and tooth, and a long burden. Where shall I find rest?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gemini