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#

• Other numbers:
  • https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=6867265&accessNumber=2158616239

Online meeting

(when we need it)

• For IBM employees, use the following link:
  • https://lli.ibm.com/meeting/join/?schedid=4446009 (IBM intranet authentication required)
• For people outside IBM, use the following link:
  • https://apps.lotuslive.com/meetings/join?id=4446009

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:

• RDF Indexer and OSLC Change Log proposal
• Indexing Proposals page (latest version)

Minutes

Attendees and notes from the meeting

Attendees

• Nick Crossley

  Robert Elves

  Frank Budinski

  Steve Speicher

  Jim Conallen

  Tack Tong

  Scott Bosworth

  Ian 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