- From: Chris Kaler <ckaler@microsoft.com>
- Date: Thu, 18 Feb 1999 17:07:32 -0800
- To: "'Bruce Cragun'" <BCragun.ORM2-1.OREM2@GW.Novell.com>, w3c-dist-auth@w3.org
Here's more feedback... [Note that I reference Bruce's comments and Jim's replies] - Jim: Excellent work pulling this together - Thanks! - It would be great if the scenarios were numbered - In "Creating a Versioned Resource": we talked about not using CHECKIN as the way this occurs. I would like to re-iterate that I think we should have a separate method. - I'm worried that the scenarios and goals assume that there are workspaces and activities. We have had some mail exchanges on the subject and I thought I would mention here that I don't believe either should be visible to a Level 1 client. - I think we need a scenario for getting a specific revision. Joe lists the history and decides that the revision whose revision id is 32345 is the desired version. Joe's client directly obtains this revision from the server. - The "Parallel Development with Activities" section leaves one with the impression that you can only do parallel checkouts via activities. I believe that Level 1 must support parallel checkouts and shouldn't require activities. - The last paragraph of "Parallel Development with Activities" confused me. If one person wants to prevent checkouts, they would lock the versioned resource not the working resource. ?? - I believe that the merge stuff is interesting but more complex than we need to address in the first draft of versioning. I think that we will find it difficult to agree on how you express the differences, the rules, communication, etc. I would rather address this stuff in a subsequent draft/effort after we get some of the simple concepts handled. - Same comment for the last paragraph of "Creating a Configuration" -- this walks into the merge path. - I don't understand how the "Changing a Revision" section is different from "Editing a Mutable Revision". Aren't they saying essentially the same thing? Or did I just miss it? :-) - The "Accessing Resources by Non-Versioning Aware Clients" assumes there is always a workspace notion. If we are describing this as a model, OK, but if the client or server have to know about this for Level 1, I think this is an issue. See previous mail. - Several times the revision "label" is used. I think people will often want to use the revision "id". - The last paragraph of "Updating Resources by Non-versioning Aware Clients" goes into a discussion of workspaces and activities. I assume that a down-level client knows neither. - Can we add a scenario about configurations related to other configuration? Alice is using the Beta1 configuration and finds a bug. She fixes the bug and checks it in. She creates a new configuration, Beta1a which consists of the "Beta1" configuration plus the changes in the "Bug1223" activity. - Goal 1: I agree with Bruce that a down-level PUT could result in the server automatically branching. - Goal 5: I believe this is needed. We see several usage scenarios where different revisions are checked out simultaneously. - Goal 15: In response to Jim's update to this goal -- I believe that both live and dead properties can be mutable (or immutable). - Goal 17: I agree with Bruce that you should be able to delete a revision without deleting its successors. However, I'm fine with saying that a server MAY refuse the request. - I think we need a Goal 22.5 that states that simple parallel development must be possible without activities. - Goal 23.1, bullet 2: I should be able to use a revision id as well - Goal 23.1, bullet 3: I should be able to checkout and create a working resource without using activities. - Goal 23.2, bullet 3: I think this should be "revision labels" since there can only be a single revision id and this section is all about labels. - Goal 23.3, bullet 3: I don't think we should be addressing merge at this point. We should constrain the problem so that we can generate a protocol. We can then layer merge semantics on top in a separate draft. - Goal 23.4, bullet 3: I should be able to access a revision using the URL of the versioned resource and a configuration name since a configuration uniquely selects a single revision. - Goal 23.4, bullet 5: I would like to add into this that is must be possible for a client to determine this. My point is that the protocol doesn't need to support this exact operation if a client, using other mechanisms, can determine this information. - Goal 31: This should be true inside or outside of an activity. Thanks for all the hard work Jim, this is starting to come together. Chris
Received on Thursday, 18 February 1999 20:07:40 UTC