Home » Archived » Eclipse Communications Framework (ECF) » ECF and relationship with JmDNS
|
| Re: ECF and relationship with JmDNS [message #624859 is a reply to message #624858] |
Fri, 15 May 2009 17:52   |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hello Thorsten,
Thorsten Möller wrote:
> Hello,
>
> I just realized today that ECF integrates the JmDNS implementation, cf.
> http://sourceforge.net/projects/jmdns/
>
> Does this mean that you have created a fork of the project that is now
> maintained independently under the ECF umbrella?
No.
Will you report back
> bugs that you fix or extensions back to the original project so that
> they actually stay the "same".
Yes. We haven't yet contributed back the (minor) changes that we've
introduced (mostly to work around some bugs)...but that's only because
we're preparing for the Galileo release and haven't had a chance to
contribute these changes back. I (Scott) am a committer on jmdns at
sourceforge, and so I don't think getting the contributions back into
jmdns is a big deal (but it is a resource thing for us/me right now as
we're/I'm doing a lot of final prep for Galileo).
If not, is it possible to get a
> stand-alone binary JAR only containing the mDNS part from the ECF
> project?
Even though the answer to the above question is 'yes' rather than 'not'
I'll answer this anyway...
We don't currently build the mDNS binary separately from the ECF jmdns
provider, but it would technically be easy to do so. The source for
this project is here:
host: dev.eclipse.org
path: /cvsroot/rt
module: org.eclipse.ecf/providers/bundles/org.eclipse.ecf.provider.j mdns
The jmdns packages are all under jmdns directory in the jmdns project.
The reason we don't do it is simply because it would require some extra
releng work, and we don't really need that at the moment.
You can create a jar yourself from the source if you wish.
>
> I'm just asking all this because I want to make up my mind whether I
> should consider to use the implementation maintained within the ECF
> project or whether I should stick to using the original project.
Up to you, of course, but I would suggest considering the ECF discovery
API, as it would allow you to use other discovery protocols and/or
implementations in supplement to/in replacement to jmdns.
Scott
|
|
| |
| UPnP discovery provider (was Re: ECF and relationship with JmDNS) [message #624861 is a reply to message #624860] |
Tue, 19 May 2009 12:33 |
Eclipse User |
|
|
|
Originally posted by: news.eclipse.org.08.lemmster.de
Thorsten Möller wrote:
> Scott Lewis wrote:
>>> I'm just asking all this because I want to make up my mind whether I
>>> should consider to use the implementation maintained within the ECF
>>> project or whether I should stick to using the original project.
>> Up to you, of course, but I would suggest considering the ECF
>> discovery API, as it would allow you to use other discovery protocols
>> and/or implementations in supplement to/in replacement to jmdns.
> Do you plan to add UPnP protocol discovery provider to ECF? Then it
> becomes interesting :-)
>
> -- Thorsten
Hi Thorsten,
ECF's architecture is open to multiple providers supporting different
discovery protocols. So while a UPnP provider is technically easily
done, I'm not aware anybody who plans to actually implement one (=needs
one).
Anyway you could start by opening an enhancement request in Bugzilla or
even better, make a contribution. :)
Markus
|
|
| |
| Re: ECF and relationship with JmDNS [message #624863 is a reply to message #624862] |
Sun, 24 May 2009 12:20 |
Dann Martens
Messages: 65
Registered: July 2009 |
Member |
|
|
Hi,
On a previous project, we 'married' different discovery mechanisms,
including mDNS (jmdns) and UPnP (Cyberlink). If I remember correctly, it
was not that straightforward to define an overarching device/service
model that allowed us to merge all the discovery data into a single
view.
Where UPnP allows a device to be declared explicitly, mDNS is
service-centric (protocol-based) and relies on indirect responders to
announce devices, such as the 'workstation' profile. In our overarching
model, we ended up defining mDNS 'phantom' devices: since there is
evidence of a service running on a device, but no direct evidence of
that device itself, the device was implied. It becomes even more
complicated after that: structural inferencing is required to resolve
the host device for different services. As mDNS will report separately
on each service hosted on a device, it became necessary to deduce that
those apparently different (implied) devices were in fact one and the same.
The 'Discovery View' which we implemented, showed devices first,
optionally broken apart into devices contained by those devices (e.g.
PCI cards) only then showing the services hosted by a device.
That was already hard enough to make us lose our appetite to put all of
that behind an ECF layer of abstraction.
@Scott: is there an impediment to make the device/service distinction in
ECF model primitives?
Best regards,
Dann
Scott Lewis wrote:
> Hi Thorsten,
>
> Thorsten Möller wrote:
>> Scott Lewis wrote:
>>>> I'm just asking all this because I want to make up my mind whether I
>>>> should consider to use the implementation maintained within the ECF
>>>> project or whether I should stick to using the original project.
>>> Up to you, of course, but I would suggest considering the ECF
>>> discovery API, as it would allow you to use other discovery protocols
>>> and/or implementations in supplement to/in replacement to jmdns.
>> Do you plan to add UPnP protocol discovery provider to ECF?
>
> We do now: https://bugs.eclipse.org/bugs/show_bug.cgi?id=277024
>
> We would/will welcome any contributions, as we're in the middle of
> preparing for Galileo release...and although a UPnP provider sounds
> great, we've got other pending requests right now.
>
> Then it
>> becomes interesting :-)
>
> Indeed.
>
> Scott
|
|
|
| Re: ECF and relationship with JmDNS [message #624864 is a reply to message #624863] |
Tue, 26 May 2009 17:37 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Dann,
Dann Martens wrote:
> Hi,
>
<stuff deleted>
> That was already hard enough to make us lose our appetite to put all of
> that behind an ECF layer of abstraction.
I empathize with the effort here in creating a common abstraction for
device/service discovery, but wouldn't it be great to prevent this same
effort for future generations of discovery users? :) IMHO it sure
would be better than living with the 'one discovery protocol to rule
them all' approach that the various protocol implementers take...and
that the software implementers have to live with).
>
> @Scott: is there an impediment to make the device/service distinction in
> ECF model primitives?
The main impediment for us: Time to define and add to the existing
discovery API (I'm assuming that it can/could be formulated as an
addition).
We can't/couldn't do this in the short term (i.e. Galileo) because of
API freeze, but we certainly could do it in ECF 4.0 (if there's enough
interest and time, of course). Also, Markus has been/is the lead for
the discovery work, so the final call is his.
But...API and code contributions...and new committers...can/would make
this a much easier decision (as always).
Thanks,
Scott
>
> Best regards,
> Dann
>
>
> Scott Lewis wrote:
>> Hi Thorsten,
>>
>> Thorsten Möller wrote:
>>> Scott Lewis wrote:
>>>>> I'm just asking all this because I want to make up my mind whether I
>>>>> should consider to use the implementation maintained within the ECF
>>>>> project or whether I should stick to using the original project.
>>>> Up to you, of course, but I would suggest considering the ECF
>>>> discovery API, as it would allow you to use other discovery protocols
>>>> and/or implementations in supplement to/in replacement to jmdns.
>>> Do you plan to add UPnP protocol discovery provider to ECF?
>>
>> We do now: https://bugs.eclipse.org/bugs/show_bug.cgi?id=277024
>>
>> We would/will welcome any contributions, as we're in the middle of
>> preparing for Galileo release...and although a UPnP provider sounds
>> great, we've got other pending requests right now.
>>
>> Then it
>>> becomes interesting :-)
>>
>> Indeed.
>>
>> Scott
|
|
|
| Re: ECF and relationship with JmDNS [message #624865 is a reply to message #624864] |
Wed, 27 May 2009 09:58 |
Dann Martens
Messages: 65
Registered: July 2009 |
Member |
|
|
Hi Scott,
Scott Lewis wrote:
> I empathize with the effort here in creating a common abstraction for
> device/service discovery, but wouldn't it be great to prevent this same
> effort for future generations of discovery users? :) IMHO it sure
> would be better than living with the 'one discovery protocol to rule
> them all' approach that the various protocol implementers take...and
> that the software implementers have to live with).
On this particular project, we have really pushed the limits in terms of
reusing what Eclipse as a platform was offering, without trying to
reinvent the wheel.
I took a very detailed look at ECF and at that time, and there just
wasn't enough common ground to justify adoption. For all of the
communication aspects of the application, we had API's in place
(provided by the frameworks we used) and it didn't feel right to put an
ECF abstraction in front of that, because we didn't need another
unifying abstraction, basically.
>>
>> @Scott: is there an impediment to make the device/service distinction
>> in ECF model primitives?
>
> The main impediment for us: Time to define and add to the existing
> discovery API (I'm assuming that it can/could be formulated as an
> addition).
The model is only part of the problem. Our main effort went into
developing the functional logic behind the system, which was really
challenging. Also the Java platform is not complete enough to solve all
of the equations: we even had to go as deep as the Link Layer, using ARP
to solve some ambiguities.
> We can't/couldn't do this in the short term (i.e. Galileo) because of
> API freeze, but we certainly could do it in ECF 4.0 (if there's enough
> interest and time, of course). Also, Markus has been/is the lead for
> the discovery work, so the final call is his.
>
> But...API and code contributions...and new committers...can/would make
> this a much easier decision (as always).
Helping the community by contributing is always high on my to-do list.
Unfortunately, some company policies prevent it. In cases where the use
of the Eclipse platform is questioned, because of company politics, it's
a luxury you simply cannot afford.
Good news is that for my RFID-enabled Eclipse IDE project, I'm back on
the ECF trail. If there is anything worth offering back in return, I
won't hesitate. Does RFID makes sense in ECF? I worked on this project
to demonstrate advanced collaboration techniques, so maybe it does...
how do you feel about that?
Also, something that might become a reality in the near future is work
on a POSIX IPC library. I have proposed the use of POSIX IPC (NamedPipe,
Semaphore, SharedMemory, ...) to further the adoption of Buckminster
(big fan, here - see buckminster-dev). Someone called Clark Hobbie
developed a very nice Java wrapper for POSIX IPC. It's early stages, but
there is a real potential to turn this into something very powerful.
The project feels orphaned a bit at the moment, and I must admit that I
was thinking whether it could find a welcoming home in the ECF project
in eventually...
Best regards,
Dann
|
|
|
| Re: ECF and relationship with JmDNS [message #624866 is a reply to message #624865] |
Wed, 27 May 2009 15:20 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Dann,
Dann Martens wrote:
> Hi Scott,
<stuff deleted>
>
> The model is only part of the problem. Our main effort went into
> developing the functional logic behind the system, which was really
> challenging. Also the Java platform is not complete enough to solve all
> of the equations: we even had to go as deep as the Link Layer, using ARP
> to solve some ambiguities.
Well, native code is possible with OSGI...but it does make life more
difficult.
>
>> We can't/couldn't do this in the short term (i.e. Galileo) because of
>> API freeze, but we certainly could do it in ECF 4.0 (if there's enough
>> interest and time, of course). Also, Markus has been/is the lead for
>> the discovery work, so the final call is his.
>>
>> But...API and code contributions...and new committers...can/would make
>> this a much easier decision (as always).
>
> Helping the community by contributing is always high on my to-do list.
> Unfortunately, some company policies prevent it. In cases where the use
> of the Eclipse platform is questioned, because of company politics, it's
> a luxury you simply cannot afford.
I understand.
>
> Good news is that for my RFID-enabled Eclipse IDE project, I'm back on
> the ECF trail. If there is anything worth offering back in return, I
> won't hesitate. Does RFID makes sense in ECF?
I don't know. Could you describe a little bit about it...perhaps on
ecf-dev at eclipse.org.
I worked on this project
> to demonstrate advanced collaboration techniques, so maybe it does...
> how do you feel about that?
>
> Also, something that might become a reality in the near future is work
> on a POSIX IPC library. I have proposed the use of POSIX IPC (NamedPipe,
> Semaphore, SharedMemory, ...) to further the adoption of Buckminster
> (big fan, here - see buckminster-dev). Someone called Clark Hobbie
> developed a very nice Java wrapper for POSIX IPC. It's early stages, but
> there is a real potential to turn this into something very powerful.
> The project feels orphaned a bit at the moment, and I must admit that I
> was thinking whether it could find a welcoming home in the ECF project
> in eventually...
I don't know anything more that what you presented about POSIX IPC so it
could be that ECF as a home would be appropriate...but I don't know.
In either case, I imagine both I and the the other members of the ECF
community would like to hear about it.
Thanks,
Scott
|
|
|
| |
  |
Goto Forum:
Current Time: Thu Apr 25 08:34:56 GMT 2024
Powered by FUDForum. Page generated in 0.03959 seconds |
] 
Search
Help
Register
Login
Home
