Eclipse Community Forums - RDF feed
https://www.eclipse.org/forums/
Eclipse Community ForumsQuestions about ECF discovery with jSLP provider
https://www.eclipse.org/forums/index.php/mv/msg/195641/623459/#msg_623459
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?
Phuong]]>Phuong Hoang2008-04-24T17:50:15-00:00Re: Questions about ECF discovery with jSLP provider
https://www.eclipse.org/forums/index.php/mv/msg/195641/623460/#msg_623460
> Hi,
Hi Phuong!
> 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"
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).
> 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?
Sounds like a bug. Can you file a ticket?
org.eclipse.ecf.provider.jslp.container.JSLPServiceInfo.getS erviceURL()
needs to remove "IANA" if set.
> 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?
This functionality is not yet available in ECF discovery, but we
definitely want to have it. Can you create an enhancement request for
it? Technically we probably want a method in
org.eclipse.ecf.discovery.IDiscoveryContainerAdapter to "query by example".
Cheers
Markus]]>Markus Kuppe2008-04-25T08:31:14-00:00Re: Questions about ECF discovery with jSLP provider
https://www.eclipse.org/forums/index.php/mv/msg/195641/623461/#msg_623461
> Phuong Hoang wrote:
>> 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?
>
> Sounds like a bug. Can you file a ticket?
> org.eclipse.ecf.provider.jslp.container.JSLPServiceInfo.getS erviceURL()
> needs to remove "IANA" if set.
On second thought, adding this check to jSLP itself sounds better. But
we might have to do it in ECF too, because switching to newer jSLP
versions takes time because of CQs.
Cheers
Markus]]>Markus Kuppe2008-04-25T09:05:15-00:00Re: Questions about ECF discovery with jSLP provider
https://www.eclipse.org/forums/index.php/mv/msg/195641/623463/#msg_623463
Cheers,
Phuong
Markus Alexander Kuppe wrote:
> On second thought, adding this check to jSLP itself sounds better. But we
> might have to do it in ECF too, because switching to newer jSLP versions
> takes time because of CQs.
>
> Cheers
> Markus]]>Phuong Hoang2008-04-25T14:40:39-00:00[Discovery] Remove create IServiceID by String (was Re: Questions about ECF discovery with jSLP prov
https://www.eclipse.org/forums/index.php/mv/msg/195641/623475/#msg_623475
>> 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).
Hi,
what do people think about dropping create IServiceTypeID and IServiceID
by String completely? Basically this means removing
org.eclipse.ecf.discovery.identity.IServiceIDFactory.
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.