ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@apache.org>
Subject Re: Integration with external platforms.
Date Sun, 03 May 2015 19:32:41 GMT
On Sun, May 03, 2015 at 04:45AM, Branko ─îibej wrote:
> On 29.04.2015 12:07, Vladimir Ozerov wrote:
> > My opinion is that a product created for particular platform (say, Python),
> > should not smell Java. Spring XML is a nice standard in Java community. But
> > I do not think that regular Node.JS/Python/Ruby/.Net/CPP developer knows
> > what Spring is.
> 
> Oh, we know what Spring is ... it's just extremely Java-centric. Or
> shall we say, JVM-centric.
> 
> > Furthermore, for now it is extremely hard to define native components in
> > Spring configuration. E.g., here is a short XML snippet on what native .Net
> > cache store configuration with a single int property looks like in Spring
> > (taken from GridGain):
> > <property name="cacheStoreFactory">
> >     <bean
> > class="org.gridgain.grid.interop.dotnet.InteropDotNetCacheStoreFactory">
> >         <property name="assemblyName" value="GridGainTest"/>
> >         <property name="className"
> > value="GridGain.Cache.Store.GridCacheTestStore"/>
> >         <property name="properties">
> >             <map>
> >                 <entry key="myProperty">
> >                     <value type="java.lang.Integer">42</value>
> >                 </entry>
> >             </map>
> >         </property>
> >     </bean>
> > </property>
> >
> > Here we force user to know Spring synthax and that Spring will treat any
> > map entry key/value as String unless it is explicitly stated that other
> > type is needed. Looks ugly and difficult.
> 
> Exactly. Outside the Java world, platform/language agnostic interfaces
> are defined in some flavour of standard-ish IDL. Or in this case, DDL.
> 
> > Instead user want to have something like this defined using some
> > industry-approved format for his platform:
> > <storeFactory>
> >     <GridGainTest#GridGain.Cache.Store.GridCacheTestStore myProperty=42 />
> > </storeFactory>
> >
> > I cannot say anything about DSL as I never worked with any, but I am 100%
> > sure that Spring XML is not an option for most other platforms.
> 
> Oh, theoretically, anyone can write code that consumes and generates
> Spring XML. I'm just not sure that it makes sense to carry along all the
> complexity for something that's, essentially, a simple structure definition.
> 
> Have you considered using the Apache Thrift IDL to define the
> interfaces? That avoids inventing yet another structural definition
> language, it's well-established and far more readable than XML, and
> binding generators for many scripting and compiled languages have
> already been written. IIRC you can use Thrift interfaces without the
> protocol baggage.

If an IDL is to consider then Thrift might be a decent option (no matter how
unpleasant my own experience with it was about 4 years back; could be the Hive
fault, actually :) Another one - Protobuf - has some serious performance
problems coming mainly from their stubborn String-copy approach (check for
yourself http://bit.ly/1GSaSVk). Notorious protoc incompatibilities (2.4.1 vs
2.5 transition was a nightmare in Hadoop project) are something to stay away
from as well.

Another some times mentioned alternative is Avro aka RPC framework, which has
certain advantages like dynamic schema, etc. However I don't see Avro gaining
any real momentum outside of Hadoop ecosystem (which IMO says a lot).
Besides, Avro supports a way fewer language bindings; their last release was
about a year ago now; the mailing lists aren't that active. Just from these
standpoints I'd be careful even considering Avro.

In general, I agree with Brane - if there's something decent that can be used
in a clean, orthogonal way to provide for easier integration with 3rd party
software - let's rather reuse it, instead of inventing (and spending time on)
our own.

Cos

P.S. And hopefully no one will seriously consider CORBA, pretty please ;)


Mime
View raw message