This wiki is locked. Future workgroup activity and specification development must take place at our new wiki. For more information, see this blog post about the new governance model and this post about changes to the website.

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)

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 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

Topic revision: r5 - 09 Feb 2011 - 16:03:25 - DaveJohnson
 
This site is powered by the TWiki collaboration platform Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use
Ideas, requests, problems regarding this site? Send feedback