tzickel / launcher-plugin-specification

0 stars 1 forks source link

Adoption by Launchers #2

Open cpriest opened 6 years ago

cpriest commented 6 years ago

Starting this thread to post topics & thoughts on launcher adoption, which would be key to this project being a success.

cpriest commented 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: [ ... ],
    }
...
tzickel commented 6 years ago

There are a few issues I see with this:

  1. How will the the plugin and launcher communicate that it's safe to do so ? There are many compatibility issues such as interpreter versions, 3rd party dependencies management, threading / event model (nothing stops the other side form doing something crazy like gevent's monkey patch and killing everything in the process). It's easier when you code for a specific launcher, where you can know what is going on.
  2. As for other communication methods such as suggested here (unix domain / tcp socket), there is nothing blocking from adding such in future versions that I know of (I rather have something simple to begin with so that the initial implementation would be easy, and that can be expanded later on if needed).
cpriest commented 6 years ago
  1. 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.

  2. I can agree with that, though none of the launchers I use could be used as it is presently written.

TheLastProject commented 6 years ago

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)

cpriest commented 6 years ago

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.

tzickel commented 6 years ago

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.