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
>
AmHome
>
ArchMgmtMeetings
>
ArchMgmtMeetings26May2011
(26 May 2011,
JimConallen
)
(raw view)
Date: *26 May 2011* <br />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* <br />Call In Number: (emailed)<br />Participation request: contact JimConallen ---++ Agenda 1 Review of active core activities ( [[OslcTrackedResourceSet][change log]], [[BaselinesInOslc][baselines]]). 1 ---++ Attendance Regrets: Brend Ellis, Eldad Palachi, John Crouchley, Steve Speicher Atendees: Clyde D. Iscuspit, Sandeep Kohli, Alanna Zito, Daniel Berg ---++ Minutes <br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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).<br /><br />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. <br /><br />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. <br /><br />The baseline resource could then be populated with snapshot references instead of resource instance URIs.<br /><br />We also discussed briefly one of the goals of the baseline proposal; to be able to compare baselines.<br /><br />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.<br /><br />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.
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 - 26 May 2011 - 21:41:35 -
JimConallen
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