Event details


  1. Scribe nomination
  2. Roll Call
  3. Approval of Apr 26 minutes

  4. Next meeting May 10, 2018

  5. Actions from the previous meeting
    • Martin to request new committee specification review
  6. Topics
    • TBD
  7. Other business

Voting Rights

Held by:







Chat transcript from room: oslc

[14:03] Jim Amsden: Scribe: Jim
[14:04] Martin Sarabura:
[14:04] Jim Amsden1: Minutes approved
[14:05] Jim Amsden1: Action: Martin setup committee specification review.
[14:06] Jim Amsden1: Action: Jim: create publishable CS02 documents for Core
[14:08] Jim Amsden1: Reviewing current activities:
[14:08] Jim Amsden1: Configuration Management:<<BR>> [14:09] Jim Amsden1: Not much change since last summary. Still waiting for the RFP for Configuration-Context header, all other issues resolved
[14:09] Jim Amsden1: Not clear this RFP needs to be done for Config-Management to go to public review
[14:11] Jim Amsden1: Nick needs to complete a few editorial issues, then we will be ready for final TC review before submitting for initial public review.
[14:11] Jim Amsden1: Nick can have this done before next weeks meeting and will be ready for TC review.
[14:12] Jim Amsden1: The same is true for TRS. Nick is making another editorial pass after Axel's work with comments on rebasing.
[14:12] Jim Amsden1: This should be done by next weeks meeting, so this should also be ready for TC review
[14:13] Jim Amsden1: Andrew would like to discuss some TRS issues
[14:13] Andrew Berezovskyi (KTH):
[14:13] Jim Amsden1: What does a server do when there are concurrent requests that have not yet finished.
[14:13] Jim Amsden1: This is the part Nick is addressing on rebasing
[14:14] Jim Amsden1: Based on IBM experience in building TRS providers, there are some approaches that work. Nick is capturing these in non-normative notes.
[14:15] Jim Amsden1: Servers should use an approach that clients can read the change logs: servers need to take in account the amount of time the clients might take to read the change log
[14:15] Jim Amsden1: this could depend on how rapidly the resources are changing.
[14:16] Jim Amsden1: Servers have techniques to minimize the change of having issues of lost data. Note the time a base page is read by a client, and allow an amount of time that base is deleted.
[14:17] Jim Amsden1: In many cases, a client should be able to process the base and change log within 6 days, keep 6 days from the previous pruning in the change log, then you're probably safe
[14:17] Jim Amsden1: This address how to keep overlap on rebase
[14:18] Jim Amsden1: but what about a client that is actively accessing the base pages. could this jump over pages on rebase?
[14:19] Jim Amsden1: The base almost never changes, you add new pages to the end of it. existing pages might have resources removed, but old pages don't have new entries - these are new pages at the end
[14:20] Jim Amsden1: Change log is also paged. If client is part way through reading the pages in the change log, and a rebase is done, the pages in the change log might loose changes.
[14:21] Jim Amsden1: But the change log is processed backwards.
[14:21] Jim Amsden1: If client can process all pages of the change log within 7 days of the cutoff event, there should be no problem.
[14:21] Jim Amsden1: pages of the change log change when the base is updated.
[14:22] Jim Amsden1: the first page is the most recent events. the next page link goes to older changes.
[14:24] Jim Amsden1: There could always be new change events after a client has read a page, but these will be handled on the next scan of the change log by that client
[14:25] Jim Amsden1: reference the client has to the next page remains valid
[14:26] Jim Amsden1: Action: Andrew
[14:26] Jim Amsden1: to clarify issues in 168
[14:27] Jim Amsden1: Action: Nick to ensure these are addressed in the non-normative guidance
[14:27] Jim Amsden1: Query Capability specification:
[14:27] Jim Amsden1: ResponseInfo was missing but can now be referenced.
[14:28] Jim Amsden1: Discussion on how to handle the oslc:orderBy and how this effects paging
[14:28] Jim Amsden1: Once these items are clarified in the spec, we can do another TC review.
[14:28] Jim Amsden1: After that we can consider when to go to initial public review.
[14:28] Jim Amsden1: David may be able to get to this in the next week or two.
[14:29] Jim Amsden1: We will also be discussing ETags later this AM. Nick is not sure the meeting is necessary.
[14:29] Jim Amsden1: There are some technical issues that need to be addressed in a reference implementation before we can discuss this.
[14:30] Jim Amsden1: There are cases where the ETag of a resource does not sufficiently capture the state of a resource for a TRS feed.
[14:31] Jim Amsden1: This might make the ETag insufficient to use a s a reliable indication of state change.
[14:31] Jim Amsden1: Internal state could change while its RDF representation doesn't. The ETag of the resource might therefore not reflect the actual state of the resource.

Meetings/Telecon2018.05.03 (last edited 2018-05-03 20:43:29 by sarabura)