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
