-- Leo's gemini proxy
-- Connecting to bbs.geminispace.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; charset=utf-8
A gaming pick for Saturday: the roguelike text adventure Kerkerkruip by Victor Gijsbers and contributors, ported to Gemini by @mbays.
I think there's something fascinating about combining text adventures with roguelikes.
2023-10-28 ¡ 7 months ago ¡ đ aRubes, Minko_Ikana
Nice to see this here. I hope it's more playable in Lagrange since the recent change to let you directly enter text without making a request first. I guess it's still annoying to have to select the input link every time, though... in diohsc you can enter "repl mode" so it's just like playing in a terminal IF client, but I guess it wouldn't make sense to add a similar mode (automatically popping up and focussing the text input box after each request) in lagrange?
You seem to be using some sort of a redirect for every input prompt (the `!?` meta command), which renders Lagrange's auto-prompting useless at the moment because the auto-prompt does not take into account redirects, only the actual URL that responded with a 1x status.
It would help if the plain `/gk/play/<hash>` URL would directly act as the input prompt without anything else in between. Should also make it faster to play in general.
A repl mode is an interesting idea for special use cases like this, I will think about it!
@skyjake: the problem is that empty input is valid input in this context, so we do need some special signal value like '!?' for the input prompt. There's no actual redirect involved, though. Afaics, the problem would be solved if lagrange considered the whole URL including query component when matching for auto-prompting, while currently it only matches with empty query component even if the original URL added to the "assume input" list has non-empty query?
> There's no actual redirect involved, though.
Hmm I see... The issue is that with the current auto-prompting method that Lagrange uses, there's nothing further to do with a URL that already includes a query string but to send it to the server. That's why only URLs without a query string can be used with the auto-prompting.
My thinking is that it seems wrong to introduce a feature where the client reacts to a particular URL by removing parts of it (the `!?` query) and offering to replace the query with something else. It would introduce a potential conflict where the app needs to discern whether the URL was opened on a page (needing to respect the query prompting rule) or whether the user typed the triggering query string manually, perhaps as a result of a prompt already having been triggered earlier (so triggering another prompt may not make sense). The current implementation has no such ambiguities.
I'll think on this a little more, though.
@skyjake It looks to me like lagrange is considering the empty query as a special case, while in the gemini protocol itself it is not special -- the empty string is just one possibility for the query string.
I don't think the protocol comes into play here. I thought on this a bit more and came away with the following. The user is applying a behavioral rule for opening a link in their client. Currently in Lagrange it is:
When opening URL A that has no query component, prompt the user for a query string before submitting so it can be appended to the URL.
To work with Gemkerkerkruip, the rule would need to be:
When opening URL A, open instead URL B and prompt the user for a query string to append to URL B.
The difference may seem subtle, but the first rule is simpler because it is purely additive: A is kept as is. The second rule is more powerful but involves somehow instructing the client about URL B. Implicitly it could be A without the query component, but not necessarily.
I don't really have a problem with the second type of rule, but I prefer the first because of its simplicity and because the client can apply it in a straightforward manner as a result of receiving a 1x status.
I may well expand this feature in Lagrange in the future, but the use case is rather specialized so it's not a high priority.
@skyjake If you think of it as replacing the query component, rather than appending to the URL, doesn't the difference go away? In the protocol, a 10 response does require you to replace the query component, rather than append.
If the auto-prompting feature's purpose is defined as causing the client to emulate the situation where a status 10 response is received after requesting a particular URL, yes, replacing the query component makes sense.
I haven't been thinking of the feature like that, though. In my mind, it's a way for the user to ensure that a chosen URL is never requested without a query string present.
I am a bit uncomfortable with the former interpretation because it makes more assumptions about how the server will behave, and doing so purely on clientside is questionable. Not saying it's bad per se; both of these interpretations rely on certain assumptions about the server/application.
I guess I'm missing something. I just sourcedived to see what's going on, and it seems to me that because of the isEmpty_Range check in postOpenLinkCommand_DocumentWidget_ in ui/documentwidget.c, enabling "assume prompt" on urls with non-empty query does nothing at all. I think I'm suggesting simply deleting that check. The feature then works with gemkerkerkruip (and various other things on my capsule which work similarly). What could it break?
I just realised a subtlety I've been missing in the above -- I'd been assuming that empty query is equivalent to no query, but actually that doesn't seem to be prescribed in the gemini spec (unless I'm missing it?), and RFC 3986 indicates that it only holds if it's explicitly mandated in the scheme spec. Spellbinding actually makes use of this, responding with 10 on no query ([...]/cgi) but not on empty query ([...]/cgi?). It's tricky to use this though -- at least with molly brown, the variables passed to cgi scripts can't differentiate between these two.
> I think I'm suggesting simply deleting that check.
It's not quite that simple. If this feature was allowed with URLs that already have a query string, the expected behavior would be that the query string in the URL is pre-filled into the query prompt, so the user can edit it before sending it out. Also, other UI changes would be necessary to enable this behavior for a given link on the page.
It would solve this particular issue with Gemkerkerkruip, I think, although perhaps not in the most elegant way. The user would still get the `!?` in the prompt and would have to overwrite it...
> empty query is equivalent to no query
According to RFC 3875 (CGI 1.1), at least in the web world the QUERY_STRING must be set to "" if the query component is missing from the URL. So CGI applications are indeed unable to make a distinction between those two cases.
I also don't think this is currently addressed in the Gemini spec, and did mention some time ago to @solderpunk that it would be nice to have an official companion spec for Gemini server CGI.
As it stands, Gemini applications don't have to use CGI, so they can check directly if a query component is present or not in the request URL and behave differently as needed. (Bubble has several cases of this, for example.)
-- Response ended
-- Page fetched on Sun May 19 17:12:49 2024