OSLC Core Meeting February 9, 2011
Last week's meeting
Link to OSLC Core spec:
OslcCoreSpecification
Meeting logistics
How to dial-in to our telecon and login to our screen-sharing session.
Telecon Info
- USA Toll-Free: 888-426-6840
- USA Caller Paid: 215-861-6239
- Participant Code: 6867265#
Online meeting
(when we need it)
- For IBM employees, use the following link:
- For people outside IBM, use the following link:
Agenda
Change Log proposal (Frank Budinsky & Nick Crossley). This session will cover a proposal for OSLC Services to each provide a change log so that RDF indexing services can be kept up to date. Relevant links:
Minutes
Attendees and notes from the meeting
Attendees
-
Nick Crossley
Robert Elves
Frank Budinski
Steve Speicher
Jim Conallen
Tack Tong
Scott BosworthIan Green
Topics discussed
Dave:
Next week: catch up on finalization and OSLC Tools issues
Frank:
Asked folks to open Word document attached to the proposal page
Idea is to allow search across tools
We want to say that this is a required feature in OSLC Core
If every tools supported OSLC Query and every resource had dc:modified, we would not need this but we don't, so this is critical
Has been prototyping this indexer internally
When things happened not as important as the order of the items
Ian asked, is the change log date really a date? or is it just a sequence number, which is really what we need
These change logs can be huge, of course. So we need OSLC paging
Scott:
Lots of questions, but not about specifics of proposal.
What are the use cases where this would be useful?
Maybe we don't need to discuss here
Frank:
Main purpose is to create a cross-service index, may have other uses
But, if it is to be used as a general purpose notification system then you'd want more details about each change
Scott:
What is scope of change log? Everything in a service? In a project?
Does the index that is built become "the truth"
Frank:
Scope is really the same scope as the Service provider's Query Capability
It's up to the provider and that could be a problem
e.g. in RTC there is no query base that allows you to navigate to users
Nick:
Change log should include at least same resources as the query capability
Perhaps a provider should have a log
Scott:
Today we have service provider as context for resources, query uses that scope
Tack:
So, there is only one log per service provider with all types of resources
Can you get change log for one type of object
Ian:
What about security, query capability may return only things you are allowed to see?
Maybe this is covered by the security proposal?
Frank:
We've had multiple thoughts on this
e.g. reader of change log is some sort of super user who can see everything
Ian:
In some cases you don't even want to allow a client to know that a resource exists if the client does not have permission to access it
Robert:
See real value in, depending on user creds, seeing deltas it the log would be useful
Frank:
That is useful, but adding that does put the burden on implementors
Robert:
Useful because we are always trying to reduce information transferred between our client and server
Could allow us to get minimal amount of changes, not have to reload complete resources
Changed attributes would really help here
Frank:
Really trying to keep thing simple, for us and implementors
Leaning towards not providing that information
We could perhaps enhance in the future.
Steve:
What about using ETag instead of date?
Frank:
ETag might be useful, but what we really need is the order
The date should perhaps be a sequence number
Scott and Dave:
Date gives you sequence, as long as it has precision enough
Ian:
But clock differences can cause problems
Frank:
We can use dates, just need to make it clear that we only need it for ordering
Don't want to get into semantics of the date
Ian:
What does date mean? Time resource was committed to a DB? Time info hit the Change Log system
If date is irrelevant then we should not force people to come up with date
Ian:
If a clock changes, then could trick indexer into thinking that a reindex is needed when it not required
Frank:
Need to discuss change entries, they are inlined into the log
Should it be allowed for each entry to be addressable
Scott:
What are the use cases for that? Do we need a representation for each entry?
Nick:
Might be a use case around security, additional information could be available at the URI
Dave:
Allowing inline or separate resource is the "default" for RDF
Dave:
What are the next steps?
Need motivating use cases
Resolve scope issues, Query Capability, Service or Service provider resource
Timestamp vs. date issue
Need to figure out how to get it into OSLC
Would have to be an optional spec at first, then could become part of OSLC vNext
Frank:
We'll talk about next steps off line
Nick:
Perhaps schedule a followup meeting
Scott:
Need to discuss on mailing list