[ANN] GemIF - Simple Interactive Fiction engine for Gemini

[Norm MacLennan]

On Thu, 3 Dec 2020, Luke Emmet wrote:
>
> I'm firmly of the camp that thinks that although there are many things the 
> web got wrong ultimately, the hypertext model is basically right (see Roy 
> Fieldin thesis and HATEOS etc). And indeed it is the established mental model 
> for textual hypertext. Breaking the "back" button on the web is generally 
> considered a bad idea and I think it is true on Gemini too for the same 
> reasons.
>
> Rather, I think we should/can make a defacto assumption of idempotence in 
> Gemini. Gemini requests are incredibly similar to HTTP GET requests, which 
> are the "idempotent" and dominant method of hypertext on the web. We don't 
> have the equivalent of the non-idempotent POST methods in Gemini. But maybe 
> there are other solutions for that, or it might come one day.
>
> So repeatedly reloading the same resource, is the equivalent to a reload, 
> hence when you go "back" it is back to the previous URL.
>
> - Luke
>

I love a lot of the self-imposed "limitations" and simplicity of Gemini 
and I definitely still have a lot of unlearning of HTTP-based habits 
and instincts still to do.

But I will also suggest that for some folks, the best part in working in 
systems with self-imposed limitations is figuring out how to push the 
boundaries, test the limits, and basically apply creative hacks to subvert 
those limitations.

All of that being said, in the particular case of GemIF, I've already 
started "Gemini-ifying" it a bit. At the suggestion of a user who emailed 
me directly rather than replying to the thread (perhaps accidentally), I've 
converted to using "state tokens". Serialized and encoded game state in 
the URL simplifies the server side and _shouldn't_ break navigation.

There's still a "pseudo-PUT" on every action you take to update your game 
state and return to you your new state token in the form of a redirect. I 
intend to have the server pre-calculate state tokens for every exit to 
construct direct links on every page and prevent the extra 
request/redirect each time.

So in this case, I would say you are absolutely right and I just needed to 
do some unlearning of habits from other protocols, but I'm not sure I'm 
willing to categorically state all requests must be idempotent. Or perhaps
I'm just willing to agree that such a thing makes sense for the spec and 
then being surprised at the crazy things people come up with when they 
start pushing the limits.