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-86) Provide TRS consumers with an efficient means of accessing tracked resources


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

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

Nick proposed an interesting potential solution on the TC call today, one that may not require any changes to the TRS specification.

A TRS provider could include elements in its base or change log that are LDPCs.
LDP already supports using the Prefer header to allow clients to express they don't want to see the members, only the properties on the container itself.
Currently a GET on the LDPC without the Prefer header would get the members. Like a TRS, they are only links.
A TRS consumer could Include a new Prefer header with GET on the LDPCs to indicate they want to see data about the members inlined in the resource.
We would need to define a Prefer value that asks for the members inline.
A TRS provider tool could publish TRS on LDPCs that do the partitioning.

A TRS provider would need to support the specification of the LDPCs, possibly often creationFactory URIs, that would be members of a TRS. 

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]