You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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?
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?
The text was updated successfully, but these errors were encountered: