Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generic Loader #103

Open
slaymaker1907 opened this issue May 14, 2017 · 2 comments
Open

Generic Loader #103

slaymaker1907 opened this issue May 14, 2017 · 2 comments

Comments

@slaymaker1907
Copy link
Contributor

I had an idea today for an easier way to support many different languages for plugins as opposed to creating a separate loader for each language. Use a loader which runs either a specified binary or a JS script (which then perhaps launches a subprocess). The plugin itself then provides information about itself through the stdout pipe.

The type information could be provided either through JSON or perhaps by printing typescript. This has the effect of being quite like the current python loader, though instead of having an explicit file provided with type info, the program itself determines this and sends it.

I thought of this when trying to figure out how best to implement a Rust loader. Unlike typescript, rustc would not be easy or simple to bundle with Sinap and might be difficulty for users to set up themselves. Therefore, instead of running the compiler in the loader, provide a library for plugin developers to use to make a Sinap plugin which will create a main function that will provide the important type information to Sinap as well as performing any necessary serailization/deserialization.

I also think this is perhaps a better long term solution since we already need to employ IPC to send graphs/inputs and outputs back and forth from the plugin process and the IDE. With this loader, the only difference would be that there is now two possible communication types: one for running graphs and one for getting type information about itself.

In effect, we would be treating plugins more like microservices in this architecture where we don't care about the underlying technologies and just rely upon a single uniform protocol.

What do you guys think?

@danielscottjames
Copy link
Member

Well the reason the typescript loader is as complicated as it is, is because we wanted the plugin to be as simple as possible. (No need to have a manifest file saying what kind of data you want or a need to use a library we provide to interact with the application; from the Plugin's perspective, it all just works.) And I vote we keep it that way because it's already done.

However, we could additionally create a "microservices" plugin loader and use that in the way you described?

@slaymaker1907
Copy link
Contributor Author

You're probably right as far as keeping the typescript loader the same.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants