Bug 207091 - [remotesvcs][Discovery] Discovery may define a generic IServiceTypeID independent of providers
Summary: [remotesvcs][Discovery] Discovery may define a generic IServiceTypeID indepen...
Status: RESOLVED FIXED
Alias: None
Product: ECF
Classification: RT
Component: ecf.discovery (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Markus Kuppe CLA
QA Contact:
URL:
Whiteboard:
Keywords: plan
Depends on: 259232
Blocks: 209774 228596
  Show dependency tree
 
Reported: 2007-10-22 16:55 EDT by Markus Kuppe CLA
Modified: 2008-12-18 11:25 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Kuppe CLA 2007-10-22 16:55:57 EDT
Until now ECF discovery has no generic IServiceTypeID. This means that consumers will have to use a provider specific IServiceTypeID (e.g. the Zeroconf/JMDNS one) to use discovery. With several providers usable simultaneously, a generic IServiceTypeID becomes necessary.
Since there seem to be no standardization attempts, discovery has to define its own representation. This representation may not cause collisions.

Below you can find the discussion leading to this bug report.

---- snip ----
> (07:25:26 PM) Markus Kuppe: do you have time to discuss another topic? it is about handling of servicetypeids from various providers and the external form of servicetypes...
> (07:29:07 PM) Markus Kuppe: basically I am currently working on a way of converting between providers. e.g. jmdns service types into jslp IServiceTypeIDs and vice versa. And a generic IServiceTypeID into specific ones. The main use case is to provide the generic IServiceTypeID to consumers and hide the specific string rep from them.
> (07:30:20 PM) Markus Kuppe: this allows consumers e.g. to register services with the generic rep at jslp/jmdns/new providers and especially transparently via the CompositeDiscoveryContainer
> (07:31:05 PM) Markus Kuppe: also they dont need to know the specific provider rep if they register as a IServiceListener
> (07:31:52 PM) Markus Kuppe: the provider specific impl of IServiceTypeID takes care of converting the generic ServiceTypeID into the provider specific as well as the other way around.
> (07:32:40 PM) Scott Lewis: so are there some needed conversion methods for IServiceTypeID?
> (07:34:03 PM) Markus Kuppe: I would like to add another constructor which takes the generic string rep (e.g. _service._ecf._foo._bar._tcp.local._IANA == _hierarchy._of_services._protocol.scope._NamingAuthority)
> (07:34:50 PM) Markus Kuppe: you can find a couple of test cases representing this at ecf1.osuosl.org:/home/cvs/ecf/tests/org.eclipse.ecf/tests.provider.jslp|jmdns
> (07:35:22 PM) Scott Lewis: OK...I'll try to take a look. Is there anything like this naming standardization going on in IETF, IANA, or others?
> (07:35:36 PM) Markus Kuppe: one thing I havent decided/Im not sure about is, whether IServiceTypeIDs from different providers should be equals if they have the same generic string rep.
> (07:36:33 PM) Markus Kuppe: i havent found an attempt of naming standardization yet, hence I used the existing Zeroconf rep and added the naming authority at the end
> (07:37:12 PM) Markus Kuppe: so it remains backward compatible.
> (07:37:38 PM) Markus Kuppe: we could decide to change the string rep with 2.0 though
Comment 1 Markus Kuppe CLA 2008-12-18 11:25:07 EST
With bug #259232 we've finally introduced a "generic" IServiceTypeID, thus marking this one as fixed. :-)