|Questions about ECF discovery with jSLP provider [message #623459]
||Thu, 24 April 2008 13:50
| Phuong Hoang
Registered: July 2009
I have some questions related to using the jslp discovery provider for ECF.
1. To specify the service type, I have to follow the syntax
_service._something ._protocol ._ scope ._ naming authority
Is it some kind of convention I have to follow? if so, it would be
great if someone can point me to it? Because when I try to register the
ServiceInfo created from the service ID using the string "service:test:slp",
I got the exception "org.eclipse.ecf.core.identity.IDCreateException:
ServiceTypeID cannot be parsed"
2. When register the service, it seems that JSLPDiscoveryContainter does
not remove the "IANA" naming authority from the service url before
registering the service. This is different from the RFC2608 requirement
which says "IANA must not be included explicitly in the service url". Is it
mistakenly left out or is there a reason to include that in?
3. I want to find the attribute for a discovered service but ECF jslp
provider does not support it. Is there a way that I can query for attribute
through ECF discovery?
|[Discovery] Remove create IServiceID by String (was Re: Questions about ECF discovery with jSLP prov [message #623475 is a reply to message #623460]
||Fri, 02 May 2008 04:40
| Markus Kuppe
Registered: July 2009
Markus Alexander Kuppe wrote:|
>> 1. To specify the service type, I have to follow the syntax
>> _service._something ._protocol ._ scope ._ naming authority
>> Is it some kind of convention I have to follow? if so, it would
>> be great if someone can point me to it? Because when I try to register
>> the ServiceInfo created from the service ID using the string
>> "service:test:slp", I got the exception
>> "org.eclipse.ecf.core.identity.IDCreateException: ServiceTypeID cannot
>> be parsed"
> ECF discovery tries to be discovery protocols agnostic. A client isn't
> supposed to see SLP, Zeroconf/Bonjour etc. Thus we've created this kind
> of "convention" which works for the moment. And as always, the code is
> the documentation. :-o
> An enhancement might be to let clients also use the protocol specific
> service syntax if they choose to expose the specific protocol/provider
> to the client. But than one might argue why not use the specific
> protocol/provider directly without using ECF discovery (for the current
> incarnation of jSLP you'll certainly loose asynchronous discovery though).
what do people think about dropping create IServiceTypeID and IServiceID
by String completely? Basically this means removing
Main reasons are:
* Makes the code overly complex because of string mangling (which is
also error prone)
* Current ECF String rep is arbitrary and non-standard
* Current ECF String rep might mismatch with new providers
* Creating objects by ctor/setters is more OOish and thus easier for the
consumer to use.
While we certainly won't be able to do this in 2.0, it is doable in 2.1
or 3.0 depending what's next.
Powered by FUDForum
. Page generated in 0.01844 seconds