Open cpriest opened 6 years ago
I think it will be very important for launchers to be able to plug-in to this specification as easily as possible which means to support at-least their ordinary "host a plugin" methodology.
From what I've seen from hain and keypirinha, this involves having a language entry-point or entry file that they load & compile into their own process. This is opposed to running some external application.
You might try having the metadata.json file indicate 'methods' to achieve the plugin' RPC endpoint.
Something like:
// json5 snippet
...
runtime: {
ipc: "calc.py",
stderr: [
{
"command": [
[ "docker", "run", "--rm", "-i", "launcherplugin/leetcalculator", "python", "calc.py" ],
[ "python", "calc.py" ],
[ "python.bat", "calc.py" ],
],
"errorMessage": "This plugin needs python or docker to run",
},
],
],
socket: [ ... ],
tcp: [ ... ],
}
...
There are a few issues I see with this:
Those are really launcher issues. The two that I mentioned load them into their own virtualized environment. In one they provide a base class which is the receiving end for the plugin and communicates to the plugin. I'm not sure exactly what KeyPirinha does but I do know that there is a base Plugin class that you're supposed to inherit from. But really all of those issues are present regardless of this standard or another, due to the way they implemented plugins.
I can agree with that, though none of the launchers I use could be used as it is presently written.
From what I've seen from hain and keypirinha, this involves having a language entry-point or entry file that they load & compile into their own process. This is opposed to running some external application.
For what it's worth, Pext does the same but does this for "simplicity's sake". Having a well defined RPC is better for everyone involved, because modules can do less nasty stuff to the launcher. I'd switch Pext over to a performant enough RPC solution in a heartbeat (I tried doing it over HTTP before but it was much too slow and heavy)
Might be an uphill battle getting those launchers to accept/rewrite their plugin process which would in many cases require plugin authors to rewrite things as well.
Don't get me wrong, I love standards, but standards that aren't adopted are just wasted time.
Launchers for the near future should support their current model, and incorporate an adapter between something like a generic launcher host in their language to their GUI (something like): https://github.com/tzickel/lps-playground/blob/master/python/launcher.py#L174 or https://github.com/tzickel/lps-playground/blob/master/nodejs/index.js
They should not do much more in their code besides that (unless I am missing something for which I am looking for feedback from their developers).
The launcher market is split between launcher written in Python, Electron (JS) and C/C++ (mostly). One of the main ideas of this specification is to allow any launcher to run any plugin in any language in any framework.
Starting this thread to post topics & thoughts on launcher adoption, which would be key to this project being a success.