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
The first pass of #230 moves all the code handling into the client wrapper, which means that each plugin needs a copy of the encoding. E.g., if a plugin uses the JSON codec, it has to not only build json_*_codec.cc, but statically link a copy of jsoncpp.
The wrapper library will probably continue to provide the generic templated codec code, for implementing custom codecs, but if possible implementations of the core codecs should be available in the shared library for ease of use. This would mean making a type hierarchy (as is needed for Standard*Codec already) that can be passed through an ABI-friendly API, so that objects can be constructed outside the library, passed in, and then converted to binary (which would need to be owned by the library and provide a deleter function).
The text was updated successfully, but these errors were encountered:
The first pass of #230 moves all the code handling into the client wrapper, which means that each plugin needs a copy of the encoding. E.g., if a plugin uses the JSON codec, it has to not only build json_*_codec.cc, but statically link a copy of jsoncpp.
The wrapper library will probably continue to provide the generic templated codec code, for implementing custom codecs, but if possible implementations of the core codecs should be available in the shared library for ease of use. This would mean making a type hierarchy (as is needed for Standard*Codec already) that can be passed through an ABI-friendly API, so that objects can be constructed outside the library, passed in, and then converted to binary (which would need to be owned by the library and provide a deleter function).
The text was updated successfully, but these errors were encountered: