OrangeTide / boris

Boris MUD - a small C plugin-based MUD for RPI or deep adventuring
http://gitlab.com/OrangeTide/boris
ISC License
12 stars 2 forks source link

Add javascript websocket front-end #17

Open OrangeTide opened 2 years ago

OrangeTide commented 2 years ago

(TODO: add a description of the intended work)

kibels commented 1 year ago

Do you need the boris server to also serve a frontend on http? You can integrate an http server but it's not totally necessary.

Or do you just want to dump the client into a folder/submodule here for a web server of your choice to serve so it's all contained in this project?

OrangeTide commented 1 year ago

I assumed boris would have a fairly comprehensive HTTP server embedded into it.

  1. It would serve static files for the .js and favicon and other images, to avoid cross-site scripting protection in all major browsers.
  2. It would server dynamic content. Templates of HTML to fill in username and other goodies for the login screen and other simple prompts (mustache templates?). And completely dynamic content of JSON generated by server-side C code.
  3. Websockets and/or long polling for the JS client to interact in near real-time.

Libwebsockets doesn't have mustache templates but theoretically could be added with mustache-c Facil.io is much bigger and more powerful than LWS and includes good mustache support. Kore.io is even bigger and fancier, but I don't think it has templates. Has great security/encryption features that the two above are lacking.

I think general architecture should be:

Given the above. I believe the answer to your question is that the JavaScript client should just be put in with the rest of the source. This seems like the easiest way to ensure that C and JS code are always in-sync on APIs.

You can either do a submodule if you want to potentially keep the client generic and port it to other MUDs. Or you can just put it into some reasonable director like src/client-js. And if you change your mind, copy it over to your other project(s).