OSLC Core Meeting April 13, 2011

Previous 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

Baselines in OSLC discussion led by Nick Crossley, continued

http://open-services.net/bin/view/Main/BaselinesInOslc

Minutes

Attendees and notes from the meeting

Attendees

• Steve S
• Jim C
• Nick C
• Frank B
• Gili M
• Arthur R

Topics discussed

Baselines discussion

Nick: let's review changes I've made

- rewrote introduction, now paraphrasing the SCM spec, uses consistent terminology

- in baselines definition, define more precisely "composite baseline"

- stated that we do not need the term "composite baseline"

- defining terms around camera: camera snapshots and the result is a "immutable snapshot, baseline or copy"

- perhaps we need a single term for the result instead of that cumbersome phrase

Steve: perhaps we have three ways that service providers can work:

1) SP exposes baselines members only

2) SP provides baseline resource itself, but no members

3) SP creates baseline within a domain, all in one domain

Nick: we want all SPs to provide camera capability, some SP needs to provide the Baseline Resources

Nick: I will clarify how many services must provide these different baselining services

Jim: what do the camera capabilities include. Must provider provide API for using the camera

Nick: Yes, that is described in the next section

Gili: it would be very help to provide some examples, what goes in, what comes out

Jim: I'm trying to rationalize. After snapshot of a workitem linked to a requirement is created in a CM system, then where is the baseline?

Nick: you'd also need a snapshot of the requirement resource. Client would have to snapshot the requirement, then modify the workitem to point to the snapshotted requirement and then snapshot the workitem

Gili: what can you use out of a snapshot resource? Just properties

Nick: current proposal is that SP must automatically rewrite links. When you snapshot a resource, the provide is responsible for rewriting links to all resources that it controls

Gili: how do you specific which resources are frozen

Nick: that is specified in the camera properties

Jim: doesn't that mean that the client must understand transitive dependencies

Jim: in AM, we end up freezing all resources in a diagram. if a client wants to use a camera to take a snapshot, the server would actually snapshot all resources. There's nothing in this spec to prevent that, no?

Nick: right, you are not preventing from snapshotting additional resources

Frank: when you create a snapshot, it may cause other snapshots, recursively

Nick: right, but only within on SP. Did not want to require communications between providers

Jim: but without that, snapshotting not that useful. We already do that and it is of limited use unless we can coordinate with other service providers. Need to freeze resources in other services, automatically

Gili: what if you provide cameras, and a camera of cameras?

Nick: but camera of cameras cannot work unless it can return URIs of all resources to be snapped, which could be difficult. Camera cannot follow resources effectively

Jim: not all internal resources are exposed that are needed to support the snapshot

Gili: camera of cameras does not need to

Jim: can camera be a two part operation? 1) freeze all non-reference properties then 2) update all reference properties

Nick: maybe that would help, but how do you know all resources to snapshot

Jim: client asks camera takes snapshot of set of resource, camera includes all other resources that it knows are needed

Nick: I will attempt to write up this two-pass approach

Nick: let's look at other issues in the next 15 minutes

Nick: finding existing snapshots? do we need this use case?

Jim: absolutely

Nick: what would a client use it to do?

Jim: change analysis over time, what is the history of a resource?

Nick: you may be expecting to much, not all providers offer versioning

Gili: why do you have reservations about using baselines for pedigree?

Nick: versioning is too different across providers, don't want spec to get into designing versioning interfaces. Do agree that baselining is the first step towards versioning, but don't want to make this first step too big.

Jim: starting to agree that you are right. Keep this simple for snapshots, and not expand to versioning, streams, etc.

Dave: time check, 5 minutes left

Dave: should we meet against next week to continue?

Nick: I'll be out of office for a couple of week, starting next week. We'll have to take this up on the mailing list...