[oslc-core] TRS spec cutoffEvent property

[Jim des Rivieres]

I had a brief side email conversation with Joe Ross and John Arwe 
off-list.  We'd like to bring it back to this mailing list.  I've 
summaried below.

---Jim

John asked me whether I thought the TRS spec required stable paging. 

==============

Jim replied to John:

I confess that I don't understand what anyone means by 'stable paging' 
with sufficient precision to answer one way or the other.  (And I've been 
out-of-the-loop with the LQE WG discussions about paging strategies). The 
current wording in the spec does not go into details of base paging per 
se.

But let me give an example of one kind of paging that would not work:

At t1 the resource set has 4 resources A, B, C, D in its base. The server 
pages the base into 2 pages with a max of 2 resources per page, say. The 
pages are the resources p1 and p2.

p1 - has resources A, B
p2 - has resources C, D

A client that reads pages p1 and p2 after t1 will correctly determine that 
the resource set has 4 resources.

At time t2, resource B is deleted from the resource set, and a 
corresponding change event is added to the TRS's change log. The server 
decides to rejig its existing pages, and delete B from p1, and shift C 
from p2 to p1 (to preserve the 2 resources per page).

p1 - has resources A, C
p2 - has resources D

A client that reads pages p1 and p2 after t2 will correctly determine that 
the resource set has 3 resources (A, C, D).

The problematic case is a client that starts reading the base before t2 
but does not complete it until after t2.

A client that reads p1 before t2 and p2 after t2 would infer that the 
resource set includes A, B, and D.  Processing the change log will kick 
out B.  So this client will incorrectly conclude the set contains 2 
resources, A and D.

The problem is clearly caused by this server mucking with how its base is 
paged - and gets burned by moving the listing for C between pages. So 
there are some plausible-looking strategies for paging the base that won't 
cut it.

==================

Joe then replied to Jim:

I agree the type of unstable paging that you describe would be a problem. 
We implemented unstable paging in such a way that items are never missed 
but they can appear again in subsequent pages if they are modified during 
the paging operation. The next page URL contains information to allow the 
server to determine that the next page should start with C instead of D.

Perhaps the TRS spec should be reworded to say that the base set should be 
implemented in such a way that a client paging through it will not miss 
any entries that existed in the base set prior to the time of the 
cutoffEvent.

==================

Jim then replied to Joe:

I agree. There should be additional words in the spec explaining the 
essential properties of base paging. I suggest adding a para like this 
after the para "Because of the highly dynamic nature of ...":

When a Base is broken into pages, the Client will discover and retrieve 
Base page resources to determine the Resources in the Base. A Client MUST 
retrieve all the page resources of the Base. A Client MAY retrieve the 
Base page resources in any order, including retrieving some Base page 
resources in parallel. A Client retrieves the Base page resources at its 
own pace, and MAY retrieve any of the Base page resources more than once. 
If the Server allows the representation of Base page resources to vary 
over time, the Server MUST ensure that the set of Resources a Client would 
infer as members is necessarily an approximation of the Resource Set 
which, when corrected by Change Events after the Base's cutoff event, 
yields the correct set of member Resources in the Resource Set.

===================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20130515/1455bac6/attachment-0003.html>