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

[Eike Stepper <stepper@xxxxxxxxxxx>]

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