[OASIS Issue Tracker] (OSLCCORE-169) Allow for more use of etags in TRS feeds

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

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

Andrii Berezovskyi commented on OSLCCORE-169:
---------------------------------------------

From the discussion yesterday (Nick):

There are legit reasons for the RDF resource representation to retain an old ETag while the underlying resource changes in the database.
----
 I think that ETag discussion here can be merged with the If-Modified-Since (where ETags are to be used for If-None-Match). As a TRS Client developer, I want to fire a request to a TRS Server (Base) and check if I need to retrieve it again. I assume if I get a "304 (Not Modified)" for either If-Modified-Since or If-None-Match, then:
 * the rebase did not occur
 * the change log (and its pages, respectively) did not change since the last request

So, I consider the implementation with the ETags and last modification dates to be quite viable. To reiterate, I actually don't care if the resource in the DB has changed. As long as I am not going to see any changes in the TRS Base or Change Log, I consider the resource(s) unchanged. The reason for it is that the TRS Client keeps a list of processed changes and I will never re-attempt to fetch the tracked resource which has already been fetched earlier when its corresponding Change Event was processed. If this is a wrong behaviour for the TRS Client, we need to spec it more precisely.

> Allow for more use of etags in TRS feeds
> ----------------------------------------
>
>                 Key: OSLCCORE-169
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-169
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Improvement
>          Components: TRS
>            Reporter: Nick Crossley
>            Priority: Major
>
> Allow TRS servers to provide more information about tracked resources, to allow both servers and clients to verify that a tracked resource set is consistent with the set and state of the tracked resources, and/or that a client has correctly processed a TRS feed.



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