Community
Participate
Working Groups
iPopo is a Python-based implementation of OSGi-like component model/service registry, and we can jointly work to create some remote service providers that interoperate with iPopo https://pypi.python.org/pypi/iPOPO
As case study potentially use https://github.com/ECF/Chat
Wiki page associated with this enhancement is here: https://wiki.eclipse.org/IPopo_Compatible_Providers
Possible IDLs to use on the wire: - (Googles) Protocol Buffers [1] -- BSD licensed - (Apache) Thrift [2] -- Apache license 2.0 (ASL is reusable at Eclipse.org without any CQ hassles) [1] https://developers.google.com/protocol-buffers/ [2] http://thrift.apache.org/
As a matter of fact, thrift 0.5 is already available from Orbit (upstream is at 0.9.1).
Some comments about comment 3 (where Markus suggests Thrift or Protocol buffers). (In reply to Markus Kuppe from comment #3) > Possible IDLs to use on the wire: > > - (Googles) Protocol Buffers [1] > -- BSD licensed > > - (Apache) Thrift [2] > -- Apache license 2.0 (ASL is reusable at Eclipse.org without any CQ hassles) > > [1] https://developers.google.com/protocol-buffers/ > [2] http://thrift.apache.org/ Yes...I would personally favor starting with Protocol Buffers over Thrift. I've been using Thrift in some Cassandra-based work, and although it works just fine (and apparently supports more languages), I find it more complex than what I've read about Protocol Buffers. I would also like to play with PB some...and this would give a chance to do that. Further, it seems that the com.google.protobuf bundles (v 2.4.0) already exist within Orbit as bundles: http://download.eclipse.org/tools/orbit/downloads/drops/R20130827064939/ So that's an advantage. I don't have any objections to Thrift though...so perhaps we do both. Scott
(In reply to Scott Lewis from comment #5) A few notes on Protocol Buffers. It seems that early-on the protocol buffers folks added some classes to support rpc...e.g. the com.google.protobuf.Service class, the RpcChannel, etc. Also...in the protoc language spec is a 'service' element...e.g.: service MyService { rpc get(MyRequest) returns (MyResponse); } which, when compiled by protoc generates java, C++, Python, etc. With the 'service' element included, the Java code generated has A) A service interface which necessarily extends the abstract Service interface B) Protocol buffer-based serialization code (for param and return values) This looks useful enough...however, it imposes some design constraints on any service that built upon it (e.g. the Service interface must be extended for any service). Also...this design note is all over the source code and documentation: Starting with version 2.3.0, RPC implementations should not try to build on this, but should instead provide code generator plugins which generate code specific to the particular RPC implementation. This way the generated code can be more appropriate for the implementation in use and can avoid unnecessary layers of indirection. [Scott] I think that for protocol buffers...for osgi remote services...the above advice is correct...i.e. if we are going to use protocol buffers for osgi remote services that what we should do is to define a new protocol buffers language element, and write a plugin for the protoc parser (which is apparently in C++. Just as an example for discussion...I could imagine something like this: osgiservice MyService config ecf.peer.rosgi { MyType get(String id); } Where when run with our protoc plugin would generate (in Java) a service interface like this: public interface MyService { public MyType get(String id); } as well as generating the protocol buffer serialization/deserialization code for MyType...in Java, C++, and Python...and perhaps even generating example host and client code for registering and accessing the remote service (e.g. using DS on java, iPopo on Python, etc). Also...using the OSGi config/container type 'ecf.peer.rosgi'...or any other. The idea here is that osgi services...in multiple languages...could be simply declared...with enhanced protoc (i.e. protoc plugin architecture to support the osgiservice element). With protoc generating the service interface and the PB marshallable param and return types. This is one idea I've had of a way to integrate protocol buffers with OSGi remote services. There might be others...that's why I'm throwing this out :). Also...FYI...here's some comments on Protocol Buffers vs. Thrift: http://stackoverflow.com/questions/69316/biggest-differences-of-thrift-vs-protocol-buffers Further, there are some serialization performance numbers for different libraries here: https://code.google.com/p/thrift-protobuf-compare/ IMHO the tough thing about serialization performance is that for some remote services it doesn't matter at all...for others obviously it will. So what's the middleware implementer to do? :). Support as many of them as possible, I guess.
Thomas has made wonderful progress on this (created a jasorb-based provider), but because of contribution/IP this work won't get into the 3.8 release, so changing target to 3.8.1
Now that ECF 3.8.1/Luna is nearly 'in the can' I would like to re-engage on this. Thomas...perhaps we can look into making the jasorb provider that you created more generally available? (e.g. building it?, example usage, etc?).
This will be undertaken via github ECF site: https://github.com/ECF
