Our base set can contain many millions of records. We absolutely do not want to implement stable paging for it. This was discussed when this draft was being prepared, and I think there was general agreement that a client could implement unstable paging. In any case, from an implementation perspective it can certainly be made work. During that discussion, the following paragraphs in the specification were referred to:
Because of the highly dynamic nature of the Resource Set, a Server may have difficulty enumerating the exact set of resources at a point in time. Because of that, the Base can be only an approximation of the Resource Set. A Base might omit mention of a Resource that ought to have been included or include a Resource that ought to have been omitted. For each erroneously reported Resource in the Base, the Server MUST at some point include a corrective Change Event in the Change Log more recent that the base cutoff event. The corrective Change Event corrects the picture for that Resource, allowing the Client to compute the correct set of member Resources. A corrective Change Event might not appear in the Change Log that was retrieved when the Client dereferenced the Tracked Resource Set URI. The Client might only see a corrective Change Event when it processes the Change Log resource obtained by dereferencing the Tracked Resource Set URI on later occasions. The Server SHOULD NOT report unnecessary Change Events although it might happen, for example, if changes occur while the base is being computed. A Client SHOULD ignore a creation event for a Resource that is already a member of the Resource Set, and SHOULD ignore a deletion or modification event for a Resource that is not a member of the Resource Set. If it is unclear that unstable paging can be supported, I think that it needs to be made clearer. Joe ================================================ Joe Ross/Austin/IBM, [email protected] Tivoli Autonomic Computing & Component Technologies 512-286-8311, T/L 363-8311 From: Jim des Rivieres <[email protected]> To: Joe Ross/Austin/IBM@IBMUS, Cc: [email protected] Date: 05/03/2013 07:14 AM Subject: Re: [oslc-core] TRS spec cutoffEvent property > Since the base set can be paged, and for very large collections, the paging can be unstable, it would be useful to include the cutoffEvent property in every page with a possibly changing value. Joe, As the spec intro puts it "the Base provides a point-in-time enumeration of the members of the Resource Set". It's important that the base is captured at a particular point-in-time, because that means resources cannot be added or removed for this base, regardless of what is happening to the resources in the set. The paging would be stable. The cutoffEvent property applies to this particular base as a whole, and there is no need to have the the cutoffEvent property in every page. This point-in-time semantics is also spelled out in the Base Resources section: "The Base of a Tracked Resource Set is a W3C Linked Data Platform (LDP) Container where each member references a Resource that was in the Resource Set at the time the Base was computed." Regards, Jim From: Joe Ross <[email protected]> To: [email protected], Date: 05/02/2013 01:31 PM Subject: [oslc-core] TRS spec cutoffEvent property Sent by: "Oslc-Core" <[email protected]> This question is related to the Tracked Resource Set 2.0 specification: http://open-services.net/wiki/core/TrackedResourceSet-2.0/ Since the base set can be paged, and for very large collections, the paging can be unstable, it would be useful to include the cutoffEvent property in every page with a possibly changing value. The specification indicates that the first page MUST include a cutoffEvent property, but doesn't seem to prohibit also including the cutoffEvent property also in subsequent pages. This is particularly useful if pages in base are shown in order of increasing modification time, which is the case in our implementation. Of course in that case, a resource can appear more than once in the base set if it is modified while someone is paging. Are there any issues with this implementation from a spec perspective? ================================================ Joe Ross/Austin/IBM, [email protected] Tivoli Autonomic Computing & Component Technologies 512-286-8311, T/L 363-8311_______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
