[OASIS Issue Tracker] (OSLCCORE-168) In the TRS spec, describe ways to ensure clients can read base+change log after pruning/rebase

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

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

David Honey commented on OSLCCORE-168:
--------------------------------------

I think the TRS spec needs some non-normative guidance about these issues. However, it should avoid being prescriptive about implementation design.

One way to get stable paging of the TRS change log is to use trs:order values in the URIs of change log pages. A client starting to traverse the most recent to the oldest would see a sequence of pages that were consistent and without gaps until it reached the last page. New events might be available, but these would be picked up the next time the client started processing the change log.

As we discused in the meeting, stable paging of the TRS base can be achieved by having persisted resources representing each base page. New entries go into the last page, or if full, ainto a new base page. TRS deletion events would result in entries in existing base pages being removed. Having an overlap between the change log and tthe base, and using this kind of base page design gives stable paging and allows the base to be read even while older events are being included in the base, and N days later (N=7 is suggested), removed from the change log. Yes, these aspects should be covered by guidance, but we shouldn't mandate an implementation design. Stable paging could be achieved in other ways.

> In the TRS spec, describe ways to ensure clients can read base+change log after pruning/rebase
> ----------------------------------------------------------------------------------------------
>
>                 Key: OSLCCORE-168
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-168
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Improvement
>          Components: TRS
>            Reporter: Nick Crossley
>            Assignee: Nick Crossley
>            Priority: Major
>
> Suppose a server has a very large number of tracked resources, and it takes a long time (weeks) to read the base, plus the change log, plus GET each of the tracked resources. Suppose a client is in the middle of that long activity when the server updates or replaces the base, and truncates the change log. The specification should have at least non-normative text describing how the server might provide sufficient information for the client to work in this case.



--
This message was sent by Atlassian JIRA
(v7.7.2#77003)