| [news.eclipse.technology.ecf] Re: supported transport mediums |
Scott,
thanks for your explanations. I will most certainly come back to this, but at the moment I'm totally busy since the EMF team offered me to incorporate my CDO persistence technology into Eclipse.org, which will last some time.
I'm following your newsgroup and your coding efforts with great interest...
Cheers /Eike
Hi Eike and Dominique,
Unfortunately, you are correct...no such page 'how to develop an ECF provider' yet exists. Emphasis on 'yet'. This is an excellent idea...and I will take on the responsibility for getting an initial cut of this page in place as soon as possible (eta: 2 weeks).
In the mean time, I'm very interested in corresponding with both of you about implementation of providers for ECF. I can/will provide direct support for such efforts. We are very keen on getting a JMS provider implementation, and, in fact, have started efforts in that direction (I've worked on an JMS provider some, but it is not complete pending some IP checking we need to do with the foundation).
Also in the mean time I would suggest the following for understanding how to implement a provider:
1) Look at the existing ECF 'generic' provider org.eclipse.ecf.provider. Particularly see the declarations in that plugin's plugin.xml and manifest.mf for the org.eclipse.ecf.containerFactory extension point. This is the key extension point for provider implementations to register themselves with ECF at bundle resolve time so that clients that make a call like the following:
ISharedObjectContainer container = SharedObjectContainerFactory.makeSharedObjectContainer("newprovidername");
and have the appropriate containerinstantiator class loaded and have it's 'makeInstance' method called at request time.
2) See the schema documentation for the 'containerFactory' extension point defined in the org.eclipse.ecf core plugin. There are some docs there already with a small amount of example code, etc. It's not very much (with apologies) but there is some there.
3) See the implementation of org.eclipse.ecf.core.SharedObjectContainerFactory. This is the factory where providers are accessed by clients.
3) See the containerinstantiator implementation class in org.eclipse.ecf.provider. The classname (for generic clients) is org.eclipse.ecf.provider.generic.ContainerInstantiator. An instance of this class is automatically accessed and called (with makeInstance(...) method) when a client makes a call to SharedObjectContainerFactory.makeSharedObjectContainer("providername");
4) Examine the code for the base 'generic container' class: org.eclipse.ecf.provider.generic.SOContainer. This is an abstract superclass that is used for both the 'client' generic container (ClientSOContainer) and the 'server' generic container (ServerSOContainer).
5) Examine the code for the generic shared object context (implements ISharedObjectContext) org.eclipse.ecf.provider.generic.SOContext.
6) See the method ClientSOContainer.getClientConnection(). Note that this method is called during the ClientSOContainer implementation of joinGroup, in order to get an instance of an object that actually communicates over the wire. Note that various transports (e.g. JMS) could be substituted for the implementation of the generic container, which is based upon a client/server simple TCP connection (see org.eclipse.ecf.provider.comm.tcp package).
7) Note that all the classes above...SOContainer, SOClientContainer, SOContext, others can be subclassed if desired. Or code patterns can be copied also if desired.
8) Please feel free to contact me directly (slewis@xxxxxxxxxxxxx) and I will provide you with support for working on provider implementations.
9) Please do not consider the code in org.eclipse.ecf.provider a 'holy relic' ;-). Although functional and reasonably bug resistant, it's not perfect and there are things I would like to change/add/refactor given time. I'm sure you could find others as well. Please don't hesitate to point them out to us/me and we will improve them as rapidly as possible.
Actually, I would like to coordinate with both/others of you so that efforts are not duplicated unnecessarily. We've already nearly finished a provider for xmpp, and have started one based upon JMS. Dominique what is the license structure for the ObjectWeb implementation of Joram? Is it compatible with the EPL?
Thanks...and please keep us informed about your plans and efforts here or in direct communication.
Thanksinadvance,
Scott
Eike Stepper wrote:
Dominique De Vito wrote:
Hi guys,
First, I want also to thank you about your session @ EclipseCon'05 and more than that, for having launched ECF.
A lot of OSS developers communicate through IRC channel, IM and so on. I think ECF could bring great features to Eclipse Platform, and at the end, could bring OSS world new common ways to develop better softwares.
I am involved into ObjectWeb community (http://www.objectWeb.org) including JORAM (JMS implementation - http://joram.objectweb.org/) and Tribe (JGroup alternative - http://tribe.objectweb.org/).
It might be an opportunity to implement an ECF Provider for these solutions.
I have just taken a look to ECF web site and not found a 'HOWTO develop an ECF Provider' page. Such page could be bring great value to ECF while attracting provider implementations, and showing that implementing a provider may be not that hard as expected.
Is it possible to define such a page ? Or such page already exists, and I have missed that one ?
I vote for this page! ;-)
/Eike
Thanks.
Dominique // Thales + ObjectWeb // working on Eclipse WTP
Scott Lewis wrote:
Hi Patrik,
If you are willing and able to do some work on implementing a provider based upon one/several of the protocols you mentioned then I would like to suggest that you work directly with me and the other ECF team members to do so...so that we can learn what additional support ECF should provide to protocol implementers to make the tasks easier.
And if your work can be contributed back to ECF/foundation, then that would be terrific, but even if not, it would be very helpful to improve the API moving forward based upon your/other's experiences in creating provider implementations. We want to make such efforts as easy as possible.
So please let us know if you are going to go down this road, and we'll coordinate/assist directly in the effort (e.g. with specific docs, answers to questions, additional supporting code in ECF, etc).
Thanks,
Scott
Patrik wrote:
Hi Scott,
Thanks for the reply...
If I manage to get something running within ECF I will be happy to contribute.
Br Patrik
"Scott Lewis" <slewis@xxxxxxxxxxxxx> wrote in message news:42312A65.2000906@xxxxxxxxxxxxxxxx
Hi Patrik,
Thanks for the nice words.
There is nothing about the basic ECF container abstraction that
requires/demands TCP-based communication. Since we've just started,
we've only implemented 2 providers of this abstraction so far...i.e. 1)
a basic tcp-based group communications and 2) a xmpp/jabber-based
provider...also based upon tcp).
It would be very nice to have additional ECF providers...implemented
upon completely different network transports...i.e. the ones you
mention. We would welcome with open arms any suggestions and/or
implementation contributions you and/or others might be willing to make!
We would like to work with people to implement the ECF container
abstraction around EPL-compatible implementations of other
communications transports...and make these available as ECF provider
plugins that application writers could use.
The ECF container abstraction does imply *some* notion of minimal
reliability/failure detection in communications, but it does not have to
necessarily be based upon TCP.
Thanks,
Scott
Patrik wrote:
Hi guys,
First, thanks for an impressive demo @ EclipseCon2005, the ECF is really
nice.
I've started to look at ECF and what it can do, but I'm missing one
piece
here...
It seems that the current impl. only addresses communication over
sockets
typically using TCP. Is there any plans to extend the framwork to
support
solutions using e.g. UART and USB or is that already possible?
Br Patrik Schalin