Open DIscussion: JS Scripting and VMs - Tradeoffs and conversations

[JeremyDOwens]

I've been looking at the js scripting stuff, and some thoughts came to mind.

Pros:

• Something can be injected/altered while the server is running
• Maybe a more familiar language for an admin/muddev

Cons:

• It's a non-trivial piece of complexity to maintain
• There's a contract between systems that makes changing things hard, but also unclear where the boundaries are
• (current implementation) There's some reliance on function naming for callbacks.

Other than providing a non-compiled option for functionality, what value proposition am I missing?
If the value is really there, perhaps there's an opportunity to make the scripting API really crisp?
Can the same functionality be implemented in go modules - minus the runtime compilation?
Is there a way to handle the concerns in the yaml configuration without the complexity of the js runtime?

Motivation for the question: I'm looking for opportunities to reduce coupling, so that new features will be easier to develop. Stuff's good now, but with additional growth there's risk of incredible slowdown.

[AngstPunk]

I agree with the risk of slowdown. Memory management can be an issue, even with a cleaner, and the possibility of JS injection is high. Have you considered putting the world files and their workings in a MariaDB (mySQL) database and then placing their running scripts in Go so that the data can be pulled from the backend, while the scripts exists only for each user as they wish from the contributions folder?

All the send messages, etc. can be kept in the database, and generic scripts can be added in Go to call them.

Just a thought.

[Volte6]

JS injection as an attack vector isn't really an issue, since no user input is run through an eval().

A database may happen in the future, but the benefits currently aren't significant... in fact, there are probably more downsides in terms of usability and work velocity.

[Volte6]

Other than providing a non-compiled option for functionality, what value proposition am I missing?
If the value is really there, perhaps there's an opportunity to make the scripting API really crisp?
Can the same functionality be implemented in go modules - minus the runtime compilation?
Is there a way to handle the concerns in the yaml configuration without the complexity of the js runtime?

Depends what you mean by "go modules", do you mean go plugins? https://pkg.go.dev/plugin

There is nothing explicitly preventing go-based code/logic... we could implement it as an alternative path if we want, but it will introduce complexity and limitations around concrete types. If we (you) can define what you think this interface should look like, we can mock up an example and decide if it's reasonable. It's possible something like what we do for our GoMud Modules could work - creating a basic API and defining callbacks, self registering, etc.

I'm less worried about slowdown - I've run this on a pretty low power setup and it works fine... but the current JS engine is not go-routine safe, so there are limitations on modern architectures. It's still not a concern as far as I can tell, though, aside from idealistic design.