Allow plugins to utilize a server for serving files and exposing HTTP endpoints for controlling SMA features, or implement IPC over HTTP.
Sketches, Videos, ...
IPC is used to get info from browser for example, we could allow a browser to request html files from SMA over HTTP
http://localhost:8000/yt.htm? -> serves yt.htm from the root dir
http://localhost:8000/nextElement -> fires an endpoint with code in SMA with a routine defined to handle it.
The behaviour is similar to RemotingServicesEx as used in the BrowserPlugin but instead you have a ServerEx which you can define endpoints on creation.
Environment
All plugins support this feature through imports.
Motivation
To implement endpoints for a UI extending the functionality and communicating with SMA over the internet. HTML could be sent to and from the extending UI to implement a new SuperMemo UI over the internet. SMA enacts the relevant changes in SM state. A big percent of the user base might use the HTTP code in this if a SM replacement UI can be made pleasant enough or virtual machines can be used in lieu of Windows requirement.
Documentation-type explanation
Same as using IPC for example in the BrowserNativeHost. The relevant methods linking endpoints can be defined. Like ServerEx.defineEndpoint("/", funcToCall, data, params)
If a sevice is implemented, I'd expect different plugins to be called by plugin name for http://localhost:8000/YouTubeJukebox/getYTUrl
Drawbacks
Data sent over HTTP may be not private. Actors could hijack the endpoints. It may be simple enough to import an external server library directly. It may be better practice to write an independent server and communicate SMA via derivatives of the existing IPC extension. Hosting a server in plugins may have too much threading overhead.
Description
Allow plugins to utilize a server for serving files and exposing HTTP endpoints for controlling SMA features, or implement IPC over HTTP.
Sketches, Videos, ...
http://localhost:8000/yt.htm?-> serves yt.htm from the root dirhttp://localhost:8000/nextElement-> fires an endpoint with code in SMA with a routine defined to handle it.The behaviour is similar to RemotingServicesEx as used in the BrowserPlugin but instead you have a ServerEx which you can define endpoints on creation.
Environment
All plugins support this feature through imports.
Motivation
To implement endpoints for a UI extending the functionality and communicating with SMA over the internet. HTML could be sent to and from the extending UI to implement a new SuperMemo UI over the internet. SMA enacts the relevant changes in SM state. A big percent of the user base might use the HTTP code in this if a SM replacement UI can be made pleasant enough or virtual machines can be used in lieu of Windows requirement.
Documentation-type explanation
Same as using IPC for example in the BrowserNativeHost. The relevant methods linking endpoints can be defined. Like ServerEx.defineEndpoint("/", funcToCall, data, params) If a sevice is implemented, I'd expect different plugins to be called by plugin name for http://localhost:8000/YouTubeJukebox/getYTUrl
Drawbacks
Data sent over HTTP may be not private. Actors could hijack the endpoints. It may be simple enough to import an external server library directly. It may be better practice to write an independent server and communicate SMA via derivatives of the existing IPC extension. Hosting a server in plugins may have too much threading overhead.