Sharlottes / MlogWatcher

the logic processor injection mod
MIT License
5 stars 3 forks source link

Allow updates via http requests #2

Closed JeanJPNM closed 9 months ago

JeanJPNM commented 10 months ago

This is a feature request that would allow triggering the mlog watcher in a way does not require writing to the filesystem, which makes integrating it with other tools such as web-based editors (like the ones provided by mindcode, go-mlog and mlogjs) much more convenient.

The idea is making the mod setup a basic http server that can receive requests that tell it to update the mlog code on the currently selected processor (just like a write to the filesystem would).

Sharlottes commented 10 months ago

thanks for giving your first issue! yes, integration with web-based editors would be awesome. but the HTTP server idea seems weird to me. how does it work?

JeanJPNM commented 10 months ago

The idea is that after the mod loads, it creates a simple (local) http server on a port that can be configured by the user.

The server can expose one endpoint that can receive POST requests (something like /submit_mlog) with json payload:

{
  "mlog": "print \"Hello world\"\nprintflush message1"
  // other fields might be added in the future
}

And on each payload received, it updates the game's currently selected processor.

And so each editor client, after generating the adequate mlog code, can make a POST request to localhost:<port number>/submit_mlog with the new mlog code.

Unfortunately I can't get into much more detail on how to implement it because I don't have much experience with java servers.

JeanJPNM commented 10 months ago

This could also be achieved using a websocket connection to receive mlog updates. Which may be more fitting due to the frequency in which updates are sent

Sharlottes commented 10 months ago

The idea is that after the mod loads, it creates a simple (local) http server on a port that can be configured by the user.

The server can expose one endpoint that can receive POST requests (something like /submit_mlog) with json payload:

{
  "mlog": "print \"Hello world\"\nprintflush message1"
  // other fields might be added in the future
}

And on each payload received, it updates the game's currently selected processor.

And so each editor client, after generating the adequate mlog code, can make a POST request to localhost:<port number>/submit_mlog with the new mlog code.

Unfortunately I can't get into much more detail on how to implement it because I don't have much experience with java servers.

@JeanJPNM I understand, but for this to be possible, a prerequisite is that "the web editor requests to a specific endpoint on the local web server". This means that I would have to put this code in all the web editors you mentioned. From a programming point of view, it seems not good for me that create a strong interdependency between mods and web editors, but anyway, I don't see how I, who is not even the owner of a web editor, can make this possible.

JeanJPNM commented 10 months ago

This proposal only aims to provide a consistent (and decently future-proof) API that allows any program to communicate with the mod to provide mlog updates. It is up to the owner of each editor to make use of this API (of course, this process can be agilized by creating a pull request).

From a programming point of view, it seems not good for me that create a strong interdependency between mods and web editors, but anyway, I don't see how I, who is not even the owner of a web editor, can make this possible.

This strong interdependency can be avoided by defining the API in a way that is agnostic to the implementation of this mod (as well as documenting it clearly), which allows anyone to create their own mod/API provider that follows the same schema and use it to replace MlogWatcher without breaking the other tools that consume said API. In short, this is a standartisation problem.

Sharlottes commented 10 months ago

At first, I didn't realize that the responsibility for editor-in-game synchronization was shared with the web editor, rather than being solely mine. I guess it's just a matter of implementation at this point. Thanks for your proposal and PR

JeanJPNM commented 10 months ago

After thinking a bit, I decided that the messages should stay as plain text representing the mlog code.

And the only setting that this feature adds is the port that the websocket server will use.

However, I do not know what should be the default port (preferrably one that is unlikely to be already in use) do you have any suggestions @Sharlottes?

Sharlottes commented 10 months ago

After thinking a bit, I decided that the messages should stay as plain text representing the mlog code.

And the only setting that this feature adds is the port that the websocket server will use.

However, I do not know what should be the default port (preferrably one that is unlikely to be already in use) do you have any suggestions @Sharlottes?

image in general, ws uses 80 port. if you're worried about duplication about port usage, consider adding some random numbers like 81, 85... or more bigger, 8123, 8005. but you must consider the range of port numbers. https://www.wikiwand.com/en/List_of_TCP_and_UDP_port_numbers