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-71) Provide data in a TRS event for filtering


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

Andrii Berezovskyi commented on OSLCCORE-71:
--------------------------------------------

Well, that would be an interesting part of the discussion. Because it triggers a bigger question of consistency of the TRS log processing, as we all know that the tracked resource in question might be updated again concurrently before the TRS client has had a chance to read the tracked resource state at the moment of the occurrence of the first ChangeEvent.

One way we are planning to deal with it in the MQTT implementation is to marshall into a single MQTT message an RDF graph containing 2 resources: both the ChangeEvent and the tracked resource in question at that particular moment. That, however, only exacerbates the need for filtering (in our case, at the MQTT topic level) and filtering based on the RDF type & the Service Provider ID is something that initially came to our mind.

Anyway, to reply to your concern regarding the edge cases, I believe the possibility of the RDF type change in most OSLC application is virtually nil. And the change of the SP concurrently twice in a short period of time is also quite slim. However, as always, the HTTP response with the resource state would always take precedence over the data in the Change Event. And it is my understanding that this is in line of the TRS spec guidance right now: if the Change Event stated that the resource was modified, but the response code for an HTTP GET on the resource is 404, we assume that the resource has been deleted.

> Provide data in a TRS event for filtering
> -----------------------------------------
>
>                 Key: OSLCCORE-71
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-71
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Improvement
>          Components: TRS
>            Reporter: David Honey
>            Assignee: James Amsden
>            Priority: Major
>              Labels: TRS
>
> Currently, a TRS event only references the tracked resource's URI. If a consumer of the TRS data is only interested in a subset of the exposed tracked resources, it has to consume the events and perform a GET on each referenced tracked resource in order to determine whether it is of interest.



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


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