[OASIS Issue Tracker] (OSLCCORE-119) Provide a way for a client to discover the configuration used to resolve a request

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCORE-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=67792#comment-67792 ] 

Nick Crossley commented on OSLCCORE-119:
----------------------------------------

Nick Crossley added a comment - 02/Jun/16 7:29 AM

Suppose GC G1 contains requirement contributions from a configuration of local component C1, and a configuration of local component C2. A requirement R1 was at some point refactored from C1 to C2. A requirement R2 exists in C1, not refactored. A GET request for R2 in G1 is easy to resolve - it is found in the local config of C1 in G1, and there's no ambiguity - but there's still some value in a client knowing a config of C1 was chosen. A GET request for R1 might be resolved in either C1 or C2, depending on the ordering of the contributions and the kind of refactoring (copy or move), so in this case the client sees significant value in getting back the identity of the local configuration used.


> Provide a way for a client to discover the configuration used to resolve a request
> ----------------------------------------------------------------------------------
>
>                 Key: OSLCCORE-119
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-119
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Improvement
>          Components: Configuration Management
>            Reporter: Nick Crossley
>            Priority: Minor
>
> The spec allows a client to provide a configuration context using either a header or a query string, but there is no way for the client to discover if this configuration was actually used, or which contribution to a global configuration was used, to satisfy the request.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)