Eclipse Community Forums: Eclipse Communications Framework (ECF) » Questions about ECF discovery with jSLP provider

Home » Archived » Eclipse Communications Framework (ECF) » Questions about ECF discovery with jSLP provider

Questions about ECF discovery with jSLP provider [message #623459]

Thu, 24 April 2008 13:50

Eclipse User

Hi,
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

Re: Questions about ECF discovery with jSLP provider [message #623460 is a reply to message #623459]

Fri, 25 April 2008 04:31

Eclipse User

Phuong Hoang wrote:
> 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

Re: Questions about ECF discovery with jSLP provider [message #623461 is a reply to message #623460]

Fri, 25 April 2008 05:05

Eclipse User

Markus Alexander Kuppe wrote:
> 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

Re: Questions about ECF discovery with jSLP provider [message #623463 is a reply to message #623461]

Fri, 25 April 2008 10:40

Eclipse User

I've filed 2 bugs, ids: 228876 and 228882 in Eclipse Bugzilla.

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

[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

Eclipse User

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).

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.

Cheers
Markus

Previous Topic:	Question about method asProperties( ) in ServiceProperties (in ECF discovery)
Next Topic:	Source code for ECF version 1.0.0.v20070215

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 23 17:01:47 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter