[ANN] GemIF - Simple Interactive Fiction engine for Gemini

[Luke Emmet]

On 03-Dec-2020 23:20, Nick Thomas wrote:
> On Thu, 2020-12-03 at 23:11 +0000, Norm MacLennan wrote:
>
>> I'm not sure I'm  willing to categorically state all requests must be
>> idempotent.
> I have the same feeling, but I think it's well-founded. Gemini requests
> don't map well to HTTP GET semantics at all - we just don't have the
> safety guarantees we need for it.
>
> A simple example - imagine I build a gemini client that prefetches all
> links on the current page in the background, for performance. If
> they're all HTTP GETs in principle, this is fine.
>
> However, like any bad web 1.0 application that used links + GET instead
> of form buttons + POST for actions, my browser will make astrobotany no
> fun to play at all, as I simultaneously water, shake, and feed my plant
> each time I visit it.

Well for all its retro quirky ascii art cuteness, Astrobotany is a bit 
of an outlier in this respect. It can get away with "abusing" gemini 
links only because it sits behind a layer of authentication, that 
restricts access to the links within the application. It would be a much 
safer application to implement in Gemini had a proper non-cacheable 
non-idempotent method.

For example, consider that GUS (and other agents) visit all our sites on 
a semi-regular basis. this means that all the links will be activated 
many times. If there is a link somewhere

=> liveendpoint click this link if you liked my article

this will be activated an aribitrary number of times, and is a mismatch 
for gemini as links in a public hypertext system are - in general - 
idempotent.

If some other contrarian gemini author put 20 (or 1000) links to that 
live end point on their gemsite, whenever GUS comes to visit, I'm going 
to get 20 new "likes"

One other point that is relevant here is that the "input" method (meta 
10 and 11) do not really help, since again they are implemented as 
parameterised links (/path/to/endpoint?inputcontent). As such they can 
be reused as persistable links.

But this is all we have in Gemini, so authors and developers do their 
best to work around the natural restrictions.

Its the same on the web - there is a limit to the types of application 
you can implement with just normal links. If you want to change state, 
you need a post method (or equivalent/JSON etc).

I'd be interested in what a non-cacheable, non-persistable, 
non-idempotent "post" type method would look like in Gemini, but at the 
moment we just have sort of hacks to try to fake it as best we can in 
some limited scenarios.

  - Luke


______________________________________