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
.
TWiki
>
Main Web
>
OslcCore
>
OslcCoreMeetings
>
OslcCoreMeeting20110413
(03 May 2011,
DaveJohnson
)
(raw view)
---+ OSLC Core Meeting April 13, 2011 [[OslcCoreMeeting20110406][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...
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r3
<
r2
<
r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r3 - 03 May 2011 - 21:02:56 -
DaveJohnson
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
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