[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (OSLCCORE-121) Allow alternative skew resolution algorithms
[ https://issues.oasis-open.org/browse/OSLCCORE-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=67799#comment-67799 ] Nick Crossley commented on OSLCCORE-121: ---------------------------------------- The risk with the proposal is that the spec will be watered down significantly - a client will not know how a server will resolve skew, and different implementations might resolve it in different ways. In particular, this might make operations with multiple different GC providers very difficult to control. Nonetheless, having a provider that resolves skew in some manner more meaningful to end users than first found may be more valuable than spec consistency for its own sake. > Allow alternative skew resolution algorithms > -------------------------------------------- > > Key: OSLCCORE-121 > URL: https://issues.oasis-open.org/browse/OSLCCORE-121 > Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC > Issue Type: Improvement > Components: Configuration Management > Reporter: Nick Crossley > Assignee: Nick Crossley > > In the current draft, a Config Mgmt server MUST provide a version resolution process using a first match in a depth-first search starting at the top of the configuration context, and MAY provide a way to find all matches. > Neither of these two algorithms necessarily meets client needs. No implementations exist for the All Matches approach. > The specification is overly precise, and its precision is not useful in this case. -- This message was sent by Atlassian JIRA (v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]