Agenda

1. Review of recent core activities.
2. Continue discussion of baseline proposal.
   1. scalability in AM domain (100's thousands of resources in a snapshot/baseline)
   2. derive pedigree, compare merge

Attendance

Regrets: Steve Speicher, Dave Johnson, Vishy Ramaswamy, Tom Picolli, John Crouchley

Atendees: Alann Zito, Clyde D. Iscuspit, Jim Conallen

Minutes

Low turnout due to vacations, and some of the Rational folk busily preparing for the Innovate conference.

We picked up on discussions from last time regarding the baseline proposal being discussed in the core. The big concern today is scalability for some systems that need to copy resources to complete a snapshot and when the transitive closure can't be computed efficiently. Design Manager (DM) fits into this category.

When DM snapshots even just a single resource, it must snapshot the entire project context. This is because the resources are highly fragmented. For some of our larger test models, the snapshot process can take from 10 minutes to 3 hours! This puts into question the proposal's approach of a simple POST with the camera capability to create a snapshot. A client is not going to wait anywhere from 10 minutes to 3 hours for a response to a POST call. The way DM does it today is that a POST is used to start a snapshot creation, but the response to the POST does not include the summary of it. Rather the client requesting the snapshot polls the server for the status of the snapshot (creating, aborted, done...). We may need the proposal to be extended to accommodate service providers with extremely long snapshot times.

In general we modeling folk think of baselines as all encompassing actions on the model. We tend not to think of baselining just a small subset of model elements (a diagram, a class, etc). One possible use case for baselines might be to support formal reviews on resources that are frozen. In these scenarios normal users will create a review on a subset of resources (models, requirements, test cases), and request a snapshot of each to include in the baseline. The review is then carried out on the baseline. Such a scenario might be carried out a couple times a day by different users. For a provider like DM this means the creation of several snapshots a day - something that will not scale in its current form today.

One idea tossed in the meeting is instead of taking a snapshot of the entire project context in the repository, we instead cache a rendering of that subset of resources (diagrams, properties, oslc responses). When clients ask for the baselined resource we return the cached resource. Of course this type of baseline would not allow the navigation through resources that were not explicitly part of the snapshot, and we could not support general querying. But it would, by orders of magnitude, increase the efficiency of baselining small sets of resources.

It was pointed out that even in this scenario a user viewing one of these baselined resources, might want click on an element in a diagram (that was not cached in the baseline) or navigate to the parent of an element or something. We see this desire in looking at historical requirements. When you look at a requirement's previous version, you often want to know what the linked, or sibling requirements were at that time as well. Similarly looking at a work item's history is only part of the view. If I note the state of a work item at a particular time, it is not easy to figure out the state of the other work items in the same project at that same time.