Re: [equinox-dev] Finding a running instance

[Thomas Hallgren <thomas@xxxxxxx>]

Hi Scott,
I'm all for using ECF. In our case, we will have the ecf.core in place 
already since we will be using file transfer API. Other factors are that 
we want to do this relatively soon and we cannot have dependencies on 
bundles that has not gone through the Eclipse.org IP process. I guess 
all of that is true for the provisioning stuff as well.

So, what do you recommend? I.e. which implementation do we need in order 
to have a working solution where we can fulfill our very modest 
requirements and do local discovery? Is it feasible to use zeroconf for 
this (I must admit my knowledge about it is somewhat limited)? Would we 
gain anything from creating yet another ecf.discovery implementation 
that is even simpler? I'm a bit unfamiliar with how SOC project works in 
terms of time line, involvement from committers etc. Can we help out 
with that? Given that this is somewhat urgent to us, should we perhaps 
start with something more heavyweight and then replace it when the SOC 
project delivers its code?

Regards,
Thomas Hallgren


> eclipse.ecf.identity:  39K
>
> Both of these also only require CDC 1.0/Foundation 1.0/Equinox.
>
> Sorry about the potential confusion.
>
> Scott
>
> Scott Lewis wrote:
> > Hi Jeff, Thomas, and Alexander,
> >
> > I don't want to sound too much like a broken record, but someone has 
> > to be the ECF advocate. :)
> >
> > The discovery API for ECF [1] (an API bundle...no implementation) is 
> > (by my definition) low overweight/low dependencies (i.e. the 
> > org.eclipse.ecf.discovery jar is 12K and it depends upon equinox 
> > common and CDC1.0/Foundation 1.0 only).  It can accomodate other 
> > providers (it already has zeroconf-based provider, one ECF committer 
> > has worked on impl using JXTA, we would love to use JINI to implement 
> > discovery, UPnP, etc), and there is a Google SOC student to do 
> > local-only service discovery provider for auto configuration:
> >
> > http://wiki.eclipse.org/An_auto-configuration_plugin_for_Eclipse
> >
> > This sounds like it might be immediately useful/relevant for Thomas' 
> > requirements...but I'm not completely sure.
> >
> > I would guess that Alexander's discovery protocol implementation 
> > could/would also be implementable as an ECF discovery API provider, 
> > but as yet I don't know enough about it to say for sure.  If not, we 
> > would enhance the API to accomodate.  We would welcome such a 
> > contribution and collaboration, of course.  FWIW, I don't, however, 
> > think it's a great idea to have multiple projects all trying to 
> > define a service discovery API based upon their particular discovery 
> > protocol.
> >
> > Thanks,
> >
> > Scott
> >
> > [1] http://wiki.eclipse.org/index.php/ECF_API_Docs#Discovery_API
> >
> >
> > Jeff McAffer wrote:
> > > As a point of interest, we have seen this kind of requirement in the 
> > > provisioning world as well.  Something simple with low overhead 
> > > makes sense...
> > >
> > > Jeff
> > >
> > >
> > >
> > > *Thomas Hallgren <thomas@xxxxxxx>*
> > > Sent by: equinox-dev-bounces@xxxxxxxxxxx
> > >
> > > 06/28/2007 03:53 PM
> > > Please respond to
> > > Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
> > >
> > >
> > > 	
> > > To
> > > 	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
> > > cc
> > > 	
> > > Subject
> > > 	[equinox-dev] Finding a running instance
> > >
> > >
> > >
> > > 	
> > >
> > >
> > >
> > >
> > >
> > > Hi,
> > > we have a use-case where one app based on the Eclipse runtime would 
> > > like
> > > to discover other running applications, also based on the Eclipse
> > > runtime, on the same machine. Does the Equinox OSGi layer contain some
> > > kind of discovery mechanism that would make this possible? If not, does
> > > anyone know of other projects that might have a solution or work in
> > > progress to solve this?
> > >
> > > Thanks,
> > > Thomas Hallgren
> > >
> > >
> > > _______________________________________________
> > > equinox-dev mailing list
> > > equinox-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> > >
> > > ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > equinox-dev mailing list
> > > equinox-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> > >   
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > equinox-dev mailing list
> > equinox-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> >   
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>