Scribe
- Jim Amsden (IBM)
Attendees
- Andrew Berezovskyi (KTH)
- Jim Amsden (IBM)
- David Honey (IBM)
- Martin Sarabura (PTC)
- Nick Crossley (IBM)
- Ian Green (IBM)
- Axel Reichwein (Koneksys)
Resolutions
Actions
- Martin to request new committee specification review
- Jim to create the published PDFs once we get the OK from OASIS
- Andrew to clarify issue 168
- Nick to ensure the issues raised in 168 are addressed in the non-normative guidance
Chat transcript from room: oslc
[14:03] Jim Amsden: Scribe: Jim
[14:04] Martin Sarabura: https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2018.04.26
[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): https://issues.oasis-open.org/browse/OSLCCORE-168
[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.
Dr. Martin Sarabura
Technical Fellow, Office of Research & Architecture
+1 (519) 502-4819
msarabura@ptc.com
ptc.com