Javascript integration
Opened this issue · 16 comments
@mhsjlw compiled protodefc to js using an emscripten target.
It would be nice to try and put protodefc in a API-similar to node-protodef module.
That way we could just replace node-protodef by that new module in node-minecraft-protocol and get perf gain.
I'm opening this here to talk about it, but there might not be anything to do about it in this repo.
So the plan is to make node-protodef more semantically similar to protodefc in the future then?
I guess.
I mean my objective here is to be able to use protodefc in prismarinejs projects.
I think it would be nice to be able to have some kind of interchangeability with node-protodef.
I think the easier to make all this happen is just to try to use protodefc in something, for example node-minecraft-protocol, so we can see what we really need in a node-protodefc api.
The part of node-protodef api we really use are the serializer/parser transform streams. So if a node-protodefc provided that, it would probably be enough.
That example only use that for example https://github.com/ProtoDef-io/node-protodef/blob/master/example.js
https://github.com/ProtoDef-io/node-protodef/blob/master/src/serializer.js
If I where to suggest a first step to actually using protodefc in anything, it would be to add a protocol.pds file in addition to a protocol.json file in minecraft-data.
It would make sense to start with a single version, then when all of the issues are ironed out, we can start thinking about adding it for multiple versions.
Would this be something you would be open to doing?
yeah I'm ok with that
I'm thinking (and willing to work on something like this):
- Some sort of build script (or task, normal script, whatever) to compile pds files to their JavaScript equivalent (see below)
- An API close enough to node-ProtoDef to be implemented externally that can be dropped into node-minecraft-protocol, PrismarineJS projects, etc.
At the same time, I'm thinking we could completely bypass the build script, protodefc is fast, why not just take the 0.01ms startup cost to compile the pds at runtime and run it though the node-ProtoDef-compatible API?
Another option is to rewrite node-ProtoDef to use this new compiler (probably the easiest) but I think it should be 100% optional and external
What features do you need runtime compilation for? Where you thinking about plugin channel messages?
Another option is to rewrite node-ProtoDef to use this new compiler (probably the easiest) but I think it should be 100% optional and external
I think it makes more sense to keep node-protodef as an interpreter and makes a new module for the compilation based version (with protodefc)
The main thing blocking this in my mind is a way to build and distribute the emscripten-compiled version of protodefc. Does anyone have any ideas how this could be done?
I was thinking
- A build server that serves a git repo with an npm module of the latest compiled protodefc
- An npm module that compiles protodefc (requires rust) and then loads it into your module
I like option 2, because when you publish your module you can publish your dist/ with the build you used, but it requires developers to have Rust installed but users don't need Rust. Option 1 can be run on Jenkins or even Travis/Circle
I think we can just have a node-protodefc that git submodule protodefc and has a prepublish script running the build for emscripten. Then npm publish and done.
No need to involve any CI, just publish a new version whenever needed.
ah yeah same thing than option 2 of @mhsjlw
What about moving protodefc js backend to npm?
@creeplays https://github.com/ProtoDef-io/protodefc-prebuilt/releases
I package asmjs-unknown-emscripten
FYI, we've settled on using WASM on platforms that do not have Rust installed, otherwise, we will build the native bindings.
I still really do not like evaling it at runtime... I'd prefer to have it be part of a build system. Would it make sense to have it build a Gulp, Webpack, Parcel, etc. plugin?