OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[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=69258#comment-69258 ] 

James Amsden commented on OSLCCORE-121:
---------------------------------------

Skew should at least be resolved consistently by a server - the algorithm shouldn't provide unpredictable or variable results depending on when the configuration is accessed.

If version skew happens in a server, and the server provides some way of resolving it, what else should a user be able to do? Should they be able to see all the resolution alternatives? If they did, what would they do with them? If a server does detect skew, and resolves it in some way, what would users do with any notification that skew resolution occurred? How would they be expected to react (other than with concern that they are not getting the right resource versions)?

All this would lead to a focus on avoiding skew in the first place rather than dealing with it after it happens. 

> 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]