Anyone wants a Zoraxy Plugin System?

[tobychui]

Hi everyone, I am currently designing a plugin system but has been stuck here for weeks. I need some inputs on how should I design a plugin system for Zoraxy. Currently I have these two ideas in mind.

Design 1

Plugin itself is a HTTP server which expose a set of specified endpoint for Zoraxy to forward requests to.

Pros

• Easy development, plugin developer can just use the native golang net/http server or even any language they want to develop the plugin, as soon as the RESTFUL API endpoints are correct, it is all good
• High speed, as it is all HTTP and do not require restructuring / reformatting of the request
• Lower level of vendor lock-in, if the plugin developer decided that he want to split it off from Zoraxy, he can easily do that by changing a few lines of code that interface with the http server
• Commercial friendly, as it is a separated part of the system that do not cover by the Zoraxy AGPL

Cons

• Platform dependent binary, just like the Zoraxy binary, each platform will require their own release version or depends on some runtime like python / npm
• Potentially dangerous, as Zoraxy need to be run as root, if the plugin is not open source, there might be potential danger in executing a third party prepackaged binary
• Harder to distribute, as you will need to ship the whole binary / wrapped in some kind of binary runtime environment like py2exe that would use up quite a lot of space

Design 2

Plugin execute within Zoraxy as a virtual machine, something like greesemonkey (the browser plugin that execute JavaScript), and Zoraxy provide a basic HTTP agent and sandbox file system for requesting external resources from the VM

Pros

• Safe, as everything run in a VM / sandbox environment
• Easy to install and distribute, just copy the script and paste in Zoraxy
• Less messy standards, as everyone will only use one intereted language (JavaScript / Lua / something else?)

Cons

• Slow, as it is run inside a VM and require real-time interpretation
• Non-standard interfaces, plugin devs will need to learn new functions and how to interact with Zoraxy instead of just following standard RESTFUL API specifications
• Not that commercial friendly, as according to AGPL, if your work require another pieces of AGPL code to work, it will be included as part of a AGPL project

Side Notes

Yes, I do know there are other implementations like the native Go plugin system (which only support linux and not quite well maintained) and similar implementations in gRPC. But since most users (and developers using Zoraxy, probably) are beginners in networking / programming, I want to make it as simple as possible to develop and use a plugin in Zoraxy. Looking forward to read all your comments and ideas :)