ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: Integration with external platforms.
Date Sun, 03 May 2015 19:45:47 GMT
On 03.05.2015 21:32, Konstantin Boudnik wrote:
> 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 ;)

Muhahahaha, why use Corba if you can go two levels of magnitude worse
with J2EE :)

-- Brane

Mime
View raw message