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.
---
Previous in thread (8 of 34): 🗣️ Luke Emmet (luke (a) marmaladefoo.com)
Next in thread (10 of 34): 🗣️ Nick Thomas (gemini (a) ur.gs)