Maybe the issue is the spec describes a DOS style 8.3 filename, which Glk doesn’t support. But Bocfel could do more to try to support what is given, either by chopping the filename at the . or by converting it to an underscore.
I know it’s a narrow reading, but that comment (about Glk not supporting filenames) is based on the language in the standard which says that the filename is suggested; and Glk’s glk_fileref_create_by_name doesn’t, or at least isn’t required to allow the user to be able to modify the name. That is, it’s no longer a suggested name, but a mandated name. The comment means that Glk doesn’t allow filenames to be suggested, not that they cannot be used.
I think my concern (I wrote that comment 7 years ago so my memory is fuzzy) was that by not allowing a suggested name, you ran the risk of a game being able to arbitrarily overwrite files. You’d have to rely on the Glk library to not allow that, basically.
I’m not sure the best approach here. Ideally there’d be a way to require the user to confirm the name with the standard interface (e.g. with a dialog box on Glk implementations that support them). An alternative, I suppose, would be “in-line” saving, using Glk directly. The result would be a UI that looks similar to how Frotz does it.
I’ll also ponder adding a Gargoyle extension to allow a filename to be suggested to the save dialog, since at least 99.9% of Bocfel users will be using it through Gargoyle.
Ah, but that’s more of an issue when the fourth operand ‘prompt’ is provided, isn’t it? Glk doesn’t let you ask for a filename with a suggested one, but if @save is only given three operands then you can just use the provided filename.
It was more ambiguous before 1.1. Now I think it’s clear that you can just use the filename, as a mandated one. With a .glkdata extension the risk to overwriting sensitive files is as low as for any other Glk game.