[news.eclipse.technology.ecf] Re: supported transport mediums

[Eike Stepper <stepper@xxxxxxxxxxx>]

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. Btw. since CDO is a Net4j protocol, the Net4j
signalling platform will also become org.eclipse.net4j.*

I'm following your newsgroup and your coding efforts with great interest...

Cheers
/Eike



Scott Lewis wrote:
> 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