💾 Archived View for rawtext.club › ~sloum › geminilist › 004969.gmi captured on 2023-09-08 at 17:32:19. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
John Cowan 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>wrote:
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).
+1
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, forexample, have two tabs (or whatever) open in my Gemini browser that referto the same access-controlled capsule, and which therefore must be accessedwith the same cert. Nevertheless, the two pages should operate as distinctsessions: I should be able to fill out a form in one page while searchinghelp 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 Geminiprotocol.
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 downall 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 ornot.
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 theuser's input, whereas if there is, we just append the user's input. Thatlets 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 comesfrom 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 URLgemini://fluffy.example/form1?session=ABC&name=John%20Cowan. Fluffy sendsthis 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 thesecond link, Fluffy will send Arfy 10 Enter your email. I typecowan at ccil.org into Aarfy, which sends the URLgemini://fluffy.example/form1?session=ABC&name=John%20Cowan&email=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 oremail 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 adatabase, or send me an email saying "HA HA HA!", or whatever it does.
Because all that happens is following links and reading input lines, itdoes not matter if Aarfy is a CLI, TUI, or GUI client: the protocolexchanges work in any case. Furthermore, Fluffy does not have to retainpartial state, because it is passed back and forth between Aarfy and Fluffywith no real interpretation at either end until Aarfy receives a submissionURL.
For that matter there is no real need to have a submission link: an URLthat 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.orgThere is no real going back. Though I may come to the Shire, it willnot seem the same; for I shall not be the same. I am wounded withknife, sting, and tooth, and a long burden. Where shall I find rest? --Frodo-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210130/c841e6c8/attachment.htm>