I won't be providing outbound HTTP (or inbound) requests via MOO code. The only I/O is what is provided through the Session interface which is, yes, transactional; all I/O "effects" are buffered and committed or reverted after the same at the DB level. Inbound HTTP is provided at the Rust layer in front of a standardized RPC interface over 0MQ and goes through the same set of transactional semantics as all other commands:
The transaction gets committed at the end of command execution, and then all the I/O that "occurred" in the narrative log gets output to its destinations. If a serialization conflict occurred, the output buffers (and all other mutations) are discarded, and everything retried, again. (In theory. Right now it just rolls back and barfs, because I have not finished this layer yet :-) )
Where this falls over is with MOO's synchronous "read" builtin, which is used in places for e.g. password changes or prompts. This is something I have not tackled yet, but will probably just have to deprecate, and will be one of the only things breaking compatibility with existing cores.
Alternatively I could or might provide a transaction mode which is "softer" for tasks that need that kind of dependent input.
It will require some thought. But on the whole MOO's model is similar to a database: In a DB it's query in, commit, see results; in my system in it's command parse, execute verb, commit, flush I/O results out.
Yeah it's tricky, but TBH I've never been comfortable with this way of interacting with the user on a MOO. It breaks the standard method of interaction there, which is command-verb based. To have the player pick from a menu... don't create a prompt... create a menu "thing" in the world and have a "choose" verb on it and ask them to interact with it.
"read" def presents a problem for the transactional model. So like I said I have basically 3 choices: not implement it, or loosen the transactional constraints for verbs that require it. the latter would be something like: as a user I accept that this could blow up at commit and require me to enter the prompt again ("I'm sorry, something went wrong and I'll need you to enter that again."), or treat it like suspend() which actually creates a new transaction (commits and then creates a new one)
The transaction gets committed at the end of command execution, and then all the I/O that "occurred" in the narrative log gets output to its destinations. If a serialization conflict occurred, the output buffers (and all other mutations) are discarded, and everything retried, again. (In theory. Right now it just rolls back and barfs, because I have not finished this layer yet :-) )
Where this falls over is with MOO's synchronous "read" builtin, which is used in places for e.g. password changes or prompts. This is something I have not tackled yet, but will probably just have to deprecate, and will be one of the only things breaking compatibility with existing cores.
Alternatively I could or might provide a transaction mode which is "softer" for tasks that need that kind of dependent input.
It will require some thought. But on the whole MOO's model is similar to a database: In a DB it's query in, commit, see results; in my system in it's command parse, execute verb, commit, flush I/O results out.