Date: 26 May 2011
Time: 7:00 AM Pacific, 10:00 AM Eastern, 3:00 PM UK, 4:00 PM Frankfurt, 5:00 PM Haifa, 7:30 PM Bangalore
Call In Number: (emailed)
Participation request: contact JimConallen

Agenda

1. Review of active core activities ( change log, baselines).

Attendance

Regrets: Brend Ellis, Eldad Palachi, John Crouchley, Steve Speicher

Atendees: Clyde D. Iscuspit, Sandeep Kohli, Alanna Zito, Daniel Berg

Minutes

Our main goal is to summarize a list of issues/recommendations regarding the core baseline proposal that are of particular interest to our AM domain.

Our primary concern is the scalability of the camera capability and snapshots. In the AM domain we have highly fragmented resources, and computing the closure of resource URIs necessary to re-render and represent may be impossible for some providers. The result is that for providers like Design Manager, even snapshotting a single resource will in turn require the entire molding context (i.e. UML model or project) to be included in the snapshot.

This means that some providers will end up creating snapshots that include nearly a million resources, and may take from 10 minutes to 3 hours to complete.

Given that a snapshot may now take three hours to create and include over a million resource URIs, we are concerned that the camera proposal will not scale for typical clients. I client will have to wait for nearly 3 hours for the return of a POST to create a snapshot, and then process the million URIs that come back (hopefully as a paged resource).

Additionally in the AM domain we are more likely to want to snapshot and entire context (project) each time, than a small subset of resources.

It would useful to be able to create a snapshot and instead of getting a list of all the URIs in the snapshp (again potentially over a million), and instead get a some moniker, perhaps a URI of the snapshot instance to use later in the creation of the baseline resource. We think that snapshots would be useful as persistent things.

The baseline resource could then be populated with snapshot references instead of resource instance URIs.

We also discussed briefly one of the goals of the baseline proposal; to be able to compare baselines.

In the AM case, using the current proposal, the baseline resources will have possibly millions of URIs in them, each opaque and unique to the snapshot'd instance of the original resource. In order to compare baselines a client will have to GET a resource's representation from one baseline, then keep GETing resources in the other baseline until it finds the one that has the same dcterms:identifier of the resource in first baseline. For a baseline with millions of resources this is daunting.

It might be useful to specify some services that a client could use to more quickly find the snapshot'd URI of a resource in a baseline, so that it would not be request to walk through the baseline one resource at a time. This might be in the form of a query on the baseline resource or some other service.