Igniters,
As we are going towards interoperability with other platforms, we need to decide how to pass data between Java and native platform. Interop layer must be able to handle the following things: 1) Process primitives; 2) Process some "java.lang" classes (arrays, String, Date, collections, maps). 3) Process limited subset of Ignite classes (e.g. metrics, events, node, etc.). 4) Read native platform objects in form of byte array or so (to save them in cache, pass over wire to other nodes, and so on). 5) Be able to read particular field of native object to support queries. I think we must introduce new interface "InteropMarshaller" which will support all these features and will be pluggable to interop configuration. Another option is try to adopt current IgniteMarshaller to serve interop purposes as well. This will allow us to easily reuse some existing marshalling codebase. But I do not think this is the right way to go for the following reasons: 1) IgniteMarshaller serves different purposes - it marshals/unmarshals the whole range of Java classes and have support for all regular serialization features (like Externalizable). Interop marshaller do not need them. 2) Default implementation - OptimizedMarhaller - heavily relies on java-specific featues (e.g. fully-qualified class names) and Ignite internals (e.g. marshaller cache which is not available direclty in native platform). Some platforms might have very specific marshalling rules which will OptimizedMarshaller will not be able to handle (e.g. dynamic object without a class associated with it, CPP struct without RTTI available, etc.). 3) As these two marshallers servers different purposes, they must evolve independently, so that change in regular marshalling do not break interop marshalling and vice versa. On the other hand, we can share IgniteMarshalelr some code base with help of refactoring. Thoughts? Vladimir. |
Vladimir,
I do like and support the idea of introducing a dedicated “InteropMarshaller”. The high level reasons are the same - InteropMarshaller can evolve independently and current fully oriented Java marshallers will not became a kind of unmaintainable universal mess. Plus, since both InteropMarshaller and Ignite(Optimized)Marshaller can(?) operate simultaneously on a cluster this solution looks good. Regards, Denis > On 15 мая 2015 г., at 23:46, Vladimir Ozerov <[hidden email]> wrote: > > Igniters, > > As we are going towards interoperability with other platforms, we need to > decide how to pass data between Java and native platform. > > Interop layer must be able to handle the following things: > 1) Process primitives; > 2) Process some "java.lang" classes (arrays, String, Date, collections, > maps). > 3) Process limited subset of Ignite classes (e.g. metrics, events, node, > etc.). > 4) Read native platform objects in form of byte array or so (to save them > in cache, pass over wire to other nodes, and so on). > 5) Be able to read particular field of native object to support queries. > > I think we must introduce new interface "InteropMarshaller" which will > support all these features and will be pluggable to interop configuration. > > Another option is try to adopt current IgniteMarshaller to serve interop > purposes as well. This will allow us to easily reuse some existing > marshalling codebase. But I do not think this is the right way to go for > the following reasons: > 1) IgniteMarshaller serves different purposes - it marshals/unmarshals the > whole range of Java classes and have support for all regular serialization > features (like Externalizable). Interop marshaller do not need them. > 2) Default implementation - OptimizedMarhaller - heavily relies on > java-specific featues (e.g. fully-qualified class names) and Ignite > internals (e.g. marshaller cache which is not available direclty in native > platform). Some platforms might have very specific marshalling rules which > will OptimizedMarshaller will not be able to handle (e.g. dynamic object > without a class associated with it, CPP struct without RTTI available, > etc.). > 3) As these two marshallers servers different purposes, they must evolve > independently, so that change in regular marshalling do not break interop > marshalling and vice versa. > > On the other hand, we can share IgniteMarshalelr some code base with help > of refactoring. > > Thoughts? > > Vladimir. |
Free forum by Nabble | Edit this page |