Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Communications Framework (ECF) » supported transport mediums
supported transport mediums [message #580400] Wed, 09 March 2005 08:23 Go to next message
Patrik is currently offline PatrikFriend
Messages: 2
Registered: July 2009
Junior Member
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
Re: supported transport mediums [message #580431 is a reply to message #580400] Fri, 11 March 2005 05:19 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 975
Registered: July 2009
Senior Member
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
>
>
Re: supported transport mediums [message #580467 is a reply to message #580431] Fri, 11 March 2005 08:04 Go to previous messageGo to next message
Patrik is currently offline PatrikFriend
Messages: 2
Registered: July 2009
Junior Member
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@composent.com> wrote in message
news:42312A65.2000906@composent.com...
> 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
> >
> >
Re: supported transport mediums [message #580487 is a reply to message #580467] Fri, 11 March 2005 22:35 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 975
Registered: July 2009
Senior Member
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@composent.com> wrote in message
> news:42312A65.2000906@composent.com...
>
>>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
>>>
>>>
>
>
>
Re: supported transport mediums [message #580551 is a reply to message #580487] Mon, 14 March 2005 10:48 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: dominique.devito.objectweb.org

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 ?

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@composent.com> wrote in message
>> news:42312A65.2000906@composent.com...
>>
>>>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
>>>>
>>>>
>>
>>
>>
Re: supported transport mediums [message #580576 is a reply to message #580551] Mon, 14 March 2005 15:32 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5586
Registered: July 2009
Senior Member
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@composent.com> wrote in message
>>> news:42312A65.2000906@composent.com...
>>>
>>>> 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
>>>>>
>>>>>
>>>
>>>
>>>
>
>
Re: supported transport mediums [message #580624 is a reply to message #580576] Thu, 17 March 2005 04:51 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 975
Registered: July 2009
Senior Member
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@composent.com) 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@composent.com> wrote in message
>>>> news:42312A65.2000906@composent.com...
>>>>
>>>>> 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
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>>
Re: supported transport mediums [message #580679 is a reply to message #580624] Thu, 17 March 2005 08:48 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5586
Registered: July 2009
Senior Member
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



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@composent.com) 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@composent.com> wrote in message
>>>>> news:42312A65.2000906@composent.com...
>>>>>
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
Re: supported transport mediums [message #580729 is a reply to message #580624] Thu, 17 March 2005 08:50 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5586
Registered: July 2009
Senior Member
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@composent.com) 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@composent.com> wrote in message
>>>>> news:42312A65.2000906@composent.com...
>>>>>
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
Re: supported transport mediums [message #581862 is a reply to message #580624] Tue, 31 May 2005 02:11 Go to previous message
Bob Balfe is currently offline Bob BalfeFriend
Messages: 17
Registered: July 2009
Junior Member
When do you think the JMS will be available as an alpha or beta?

--
Bob
IBM Software Group
Workplace Client Technology Platform, Rich Edition
"Scott Lewis" <slewis@composent.com> wrote in message
news:42390CBF.9060105@composent.com...
> 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@composent.com) 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@composent.com> wrote in message
> >>>> news:42312A65.2000906@composent.com...
> >>>>
> >>>>> 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
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>>
> >>
> >>
Previous Topic:ECF Discovery API: NEW
Next Topic:Using ECF as an Enterprise service Bus framework?
Goto Forum:
  


Current Time: Thu Dec 18 02:33:12 GMT 2014

Powered by FUDForum. Page generated in 0.10248 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software