-
Notifications
You must be signed in to change notification settings - Fork 10
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
Support different serialization formats #108
Comments
Great suggestion. We'll still use "Record Serialization"/JSON5 syntax for custom DSLs like metadata, IDLs and stuff, but using pluggable serialization formats for protocol messages certainly gives us benefits. When we'll send arrays with pure data only, and metadata being separated, there'll be nearly no difference in using our format or JSON. Except performance. A custom parser of JSON5-like format that only uses public V8 APIs is very unlikely to ever be even as fast as JSON, not to mention faster. It will also be possible to use JSRS/JSON5 or JSON during development and a binary format for production mode and gain even more performance without sacrificing human-readable messages format when we need it. |
Yeah, I totally agree, that's a nice idea. Having much faster message parsing and serialization can highly increase overall protocol performance. @tshemsedinov, what is your opinion on this topic? |
Agree. We will have separated features divided by fixed interfaces: parser, transport, rpc, storage. So different implementations may be used in any combination. |
Paused because we don't need this functionality in near future |
Now JSTP works only with one
JSON5
like serialization format. While it would be much more extendable use abstract interface that provides such functions as:parse()
serialize()
parseNetworkPacket()
serializeNetworkPacket()
This way will be able to add new formats, for example
JSON
or some binary format.The text was updated successfully, but these errors were encountered: