[OASIS Issue Tracker] (OSLCCORE-86) Provide TRS consumers with an efficient means of accessing tracked resources

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

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

James Amsden commented on OSLCCORE-86:
--------------------------------------

Nick's approach organizes collections of resources whose contents one might want to obtain in a single GET request in an LDPC. This could result in some coupling between the use of tracked resources and the persistence structure of the server.

It is important to distinguish a server's persistence architecture, or how it organizes information in its repository for its purposes, and the different purposes a client might have in accessing that data. Flexible definitions of TRS resources provided by a server will allow clients to get the data they need for their purposes and keep it efficiently updated. So the organization of the data from the consumer's perspective may often be different than that of the provider.

Servers might provide some view-like mechanism to define virtual LDPCs that provide flexible, extensible, varying or perhaps even dynamic organization of their data.

Alternatively, we could consider separating the organization of data by the TRS provider from the organization from the perspective of the user.

1. When a TRS is defined, members of the set can be organized into named partitions (groups, sets, collections, whatever we want to call it).

2. These sets are defined in the TRS base and are also used to partition events in the change log.

3. TRS polling works as usual. Without the partitioning, it is transparent to TRS clients that don't use the facility

4. TRS clients MAY do a GET on the partition to obtain a resource that has inlined representations of the resources in that partition.

5. The usual OSLC selected properties query strings can be used with the partition query parameter to obtain a subset of the resource properties

This would allow different TRS feeds to be created for different purposes on the same server data sources. 

> Provide TRS consumers with an efficient means of accessing tracked resources
> ----------------------------------------------------------------------------
>
>                 Key: OSLCCORE-86
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-86
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>            Reporter: James Amsden
>            Assignee: James Amsden
>
> A TRS defines a base of member resources and a change log of creation, deletion or modification change events. The member and changed elements are URLs to the resources, the TRS does not contain any data from the resources themselves. 
> A TRS change event can include a TRS Patch element that provides the changed property values without requiring the TRS consumer to do an additional GET on the resource. 
> However in most cases, a TRS consumer that needs actual resource data from base or changed members of a TRS will need to do individual GETs on each of the resources in order to establish initial copies, or update existing copies.
> This can be a very inefficient and time consuming process for TRS resources that have a large number of rapidly changing members.
> There is a need to provide a more efficient way of getting information from more than one tracked resource at a time so the GETs can be batched together and included inline in a resource.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)