[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Finding a running instance

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