Glk is limited to 11 styles, but there is little technical reason for this. This extension raises that number to 255. Additional styles are referred to with their number, so style 11 is style_User11 (or Style_user11 in GlkOte), not style_User3.
Support for additional styles can be tested with gestalt_ExtraStyles (Gestalt code TBA). You can also make a preprocessor test for GLK_MODULE_EXTRA_STYLES.
Many authors would like to be able to open a URL from their games. Some interpreters will autolinkify a URL that has been printed, but not all, and that necessitates printing the entire URL. This function allows authors to directly open a URL.
Support for this function can be tested with gestalt_OpenURL (Gestalt code TBA). You can also make a preprocessor test for GLK_MODULE_OPEN_URL.
// Function code: TBA
void glk_open_url(char *url, glui32 urllen);
The URL must be ASCII (pre-encode any higher character codes). Only one URL can be opened per input cycle; opening a second will replace the first. You should only attempt to open a URL in response to player action as web interpreters are restricted (so don’t open a URL in response to a timer event.)
I think I can implement these in Parchment without much difficulty, though I’ll need to check that browsers don’t think the Glk IO cycle is too indirect to allow opening a new tab.
I’m cautious of a Glk call to open a URL, because it increases the attack surface a lot. A Glulx file can now download arbitrary files onto the user’s device unless the browser specifically prevents it. (Not that there are a lot of people currently trying to distribute malware via IF VM bytecode, but you never know…) You mention the web interpreter putting restrictions on this, but I think it’s better to put security into the spec, not leave it to the individual implementations.
The Å-machine only allows opening URLs when the player clicks on a link—that is, there’s no mechanism to open a URL, only to display a link that leads to a URL. Which means if anything gets downloaded, it happens in a way the user is (hopefully) familiar with. I think that would be a good idea for Glk as well.
Hmm, I guess a zero-day exploit (in which simply opening a webpage or downloading a PDF or whatever compromises your computer) is a possibility, but the risk seems so extremely low. There’s no particular vulnerability here compared to anywhere else on the internet.
Having glk_open_url as a function means that it wouldn’t be restricted to hyperlinks. It could be used after keyboard input, or clicking in a graphics window.
But it should probably be restricted to http:, https:, and mailto:.
Downloading a file probably isn’t immediately dangerous, but letting Glulx games access the internet without restriction seems like it opens up a lot more opportunities for problems. There was that thread a couple weeks ago, for example, where people didn’t like the privacy implications of IFComp automatically recording transcripts. I don’t think those people would be happy if games run in offline interpreters could now send data to a remote server at any time, and the only way to stop it was to put your device into airplane mode before launching Gargoyle.
(Putting it behind a link doesn’t necessarily fix this problem, of course. But people are a lot more used to clicking a link giving the web browser permission to Do Something New, even if that’s sometimes not what you wanted. The Å-machine fixes this by only allowing URLs that are compile-time constants, so you can’t put a bunch of data in a query string at runtime, but I can’t think of any elegant way to do that in the Glk architecture, and dynamic URLs have plenty of advantages too, like showing a dynamic ending screen based on your choices in the game.)