Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[dsdp-tcf-dev] [Bug 281259] New: [tcf][api] Support Capabilities in TCF framework to manage protocol extensions / semantics 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=281259  
Product/Component: Target Management / TCF
           Summary: [tcf][api] Support Capabilities in TCF framework to
                    manage protocol extensions / semantics
           Product: Target Management
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: api
          Severity: enhancement
          Priority: P3
         Component: TCF
        AssignedTo: dsdp.tm.tcf-inbox@xxxxxxxxxxx
        ReportedBy: martin.oberhuber@xxxxxxxxxxxxx
         QAContact: martin.oberhuber@xxxxxxxxxxxxx
                CC: martin.gutschelhofer@xxxxxxxxxxxxx,
                    uwe.stieber@xxxxxxxxxxxxx, tobias.schwarz@xxxxxxxxxxxxx


The TCF Discovery protocol defines a method for obtaining key/value pairs that
describe the remote system. But it does not specify what specific keys are
supported, or what their meaning is.

Multiple different vendors can implement specific key/value pairs with specific
semantics. It would be good if the TCF IService interface would allow to query
a service for the capabilities that it supports: Where each capability is a
String in reverse DNS notation, e.g.

String[] capabilities = myService.getCapabilities();
if (Arrays.asList(capabilities).contains("com.foo.theCapabilitiy")) {
   /* perform code which requires given capability */
}

Capabilities are binary, i.e. any capabilitiy is either available in a specific
service implementation or not. Looking at available capabilities, a client can
then decide whether it can make use of a specific provided service or not.

There are other usage scenarios for capabilities, especially
backward-compatible protocol extensions. I am aware that in general, TCF would
strive for a new service ID when a particular service is extended or modified.
The drawback of using a completely new ID is that backward-compatible protocol
extensions are a lot effort to code against in the client.

Keeping the same protocol name around for backward compatible extensions, but
then marking existence or non-existence of specific capabilities with a
Capabilitity specifier as proposed enough seems to be a much easier way for
such backward compatible extensions.


-- 
Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

Back to the top