[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [dsdp-tm-dev] autodetect
|
I'm no Zeroconf expert by my understanding is that it is used to
discover interfaces and network services on remote machines. Do you
know if it can be used to discover of other types of configuration
information (e.g. architecture information, installed packages, etc.)?
Greg
On May 3, 2006, at 7:50 AM, javier.montalvoorus@xxxxxxxxxxx wrote:
Hi,
I have been taking a look at the ECF for Service Discovery and, as
Scott and Martin suggested, we could use it for the TM autodetect
process.
Testing it with the Apple's Bonjour SDK ( http://
developer.apple.com/bonjour ), that contains a sample application
to register Bonjour/Zeroconf services, the Dynamic Service
Discovery View from ECF correctly displays the registered services
in the same network. This facility it what we want in the
autodetect process, so using ECF should be fine.
For those interested on how Bonjour / Zeroconf works, there is a
quite interesting tech talk from Stuart Cheshire at:
http://video.google.com/videoplay?
docid=-7398680103951126462&q=Google+techtalks
Although Zeroconf seems a good solution for autodetect, does
anybody have other alternatives worth to be considered or any
inconvenient using Zeroconf ?
Regards,
Javier Montalvo OrĂºs
Engineering Tools
Symbian Software Limited.
Tel: +44 (0)207 154 1091
"Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
Sent by: dsdp-tm-dev-bounces@xxxxxxxxxxxx
27/04/2006 10:56
Please respond to
Target Management developer discussions <dsdp-tm-dev@xxxxxxxxxxx>
To
"Target Management developer discussions" <dsdp-tm-dev@xxxxxxxxxxx>
cc
Subject
FW: [dsdp-tm-dev] autodetect
FYI,
comments from Scott Lewis (ECF) regarding autodetect, Zeroconf /
Bonjour, DNS-SD and ECF.
From: Scott Lewis [mailto:slewis@xxxxxxxxxxxxx]
Sent: Thursday, April 27, 2006 2:53 AM
To: Oberhuber, Martin
Subject: Re: FW: [dsdp-tm-dev] autodetect
Hi Martin,
No, you've got everything right! And thanks!!
See a couple of supporting comments inline.
From: dsdp-tm-dev-bounces@xxxxxxxxxxx [mailto:dsdp-tm-dev-
bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin
Sent: Wednesday, April 26, 2006 4:01 PM
To: Target Management developer discussions
Subject: RE: [dsdp-tm-dev] autodetect
Hello Javier,
these are very interesting pointers and ideas.
I had a look at http://www.dns-sd.org and I got the feeling that it
is an extension of what
Apple's Zeroconf / Bonjour does on the LAN, to the wide area
network through the DNS
transport mechanisms.
Yes...that's right. Zeroconf/Bonjour uses dns-sd service type/
service naming conventions though...so that everything will work
beyond the lan environment at the appropriate time.
What I found most interesting on the page, was the list of
standardized protocol names
which they use in their descriptive strings for the services:
http://www.dns-sd.org/ServiceTypes.html
I guess we could definitely use those to publish existence of
services, regardless of what
sort of protocol / transport we finally choose to use.
In fact, I've already seen these specifiers before in the ECF
discovery. ECF already has
a provider implementation for Zeroconf / Bonjour, which uses the
same strings.
Consequently, looking at the ECF Discovery API might be the next
logical step for us.
Yes...ECF abstracts the dns-sd service type info (represented as
String by jmdns) as an org.eclipse.ecf.core.identity.ServiceID (of
sub-type defined by the jmdns Namespace extension...i.e.
JMDNSServiceID).
What I'm not so sure about is, if running a DNS server on the
device is the right thing to
do. There are already devices like printers etc. implementing
Zeroconf / Bonjour, and I
don't think they run full-blown DNS servers. When I'm not mistaken,
it's a very simple
protocol.
Yes, Zeroconf/Bonjour is a very simple protocol. If you are only
interested in a lan-based discovery via zeroconf, it's not even
necessary to run DNS anywhere...and I think you can make up service
types/service names with anything you want (i.e. you don't have to
have a dns-sd name). For example, I defined an _ecftcp service
type. But if you want to do dns-sd discovery across lans, then DNS
(at least some DNS server) and dns-sd names does become necessary.
But you can use ecf discovery with the jmdns provider protocol to
publish services and receive asynch callbacks about the network
availability of those services easily enough right now with ECF.
For example:
IContainer container = ContainerFactory.getDefault().createContainer
("ecf.discovery.jmdns");
container.connect(null,null);
IDiscoveryContainer dc = (IDiscoveryContainer) container.getAdapter
(IDiscoveryContainer.class);
// use dc to register services or to setup service listeners
Also, there's example code in the org.eclipse.ecf.example.collab
plugin that sets up a little ECF Discovery view that shows services
discovered on the LAN via zeroconf. See
org.eclipse.ecf.example.collab.DiscoveryStartup.setupDiscovery
(). The view class is:
org.eclipse.ecf.example.collab.CollabDiscoveryView. The
'setDiscoveryController' method gets called in the
CollabDiscoveryView constructor.
Scott
_______________________________________________
dsdp-tm-dev mailing list
dsdp-tm-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
*******************************************************************
*** Symbian Software Ltd is a company registered in England and
Wales with registered number 4190020 and registered office at 2-6
Boundary Row, Southwark, London, SE1 8HP, UK. This message is
intended only for use by the named addressee and may contain
privileged and/or confidential information. If you are not the
named addressee you should not disseminate, copy or take any action
in reliance on it. If you have received this message in error
please notify postmaster@xxxxxxxxxxx and delete the message and any
attachments accompanying it immediately. Neither Symbian nor any of
its Affiliates accepts liability for any corruption, interception,
amendment, tampering or viruses occurring to this message in
transit or for any message sent by its employees which is not in
compliance with Symbian corporate policy. *************************
*********************************************
_______________________________________________
dsdp-tm-dev mailing list
dsdp-tm-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev