[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] Finding a running instance
|
An ECF based solution may be fine for this particular usecase. However I
don't think it will suitable for other scenarios like invocation from a non
eclipse based application or from a web browser (see SOC
http://wiki.eclipse.org/Eclipse_Web_Interface).
Thomas which kind of operation are you trying to execute on the remote
eclipse?
Thomas Hallgren
<thomas@xxxxxxx>
Sent by: To
equinox-dev-bounc Equinox development mailing list
es@xxxxxxxxxxx <equinox-dev@xxxxxxxxxxx>
cc
06/30/2007 06:57 Subject
AM Re: [equinox-dev] Finding a running
instance
Please respond to
Equinox
development
mailing list
<equinox-dev@ecli
pse.org>
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
>
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
