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 <[email protected]> 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.
