Hi Christopher, thanks for your response.
> - History numbers: I assume using 'auto-increment'-style numbers here > is to support renaming/moving of resources, i.e. a resource is not > tied to the name it was originally created with, as is in CVS (of > course using auto-inc numbers doesn't look totally elegant, so I'm > asking for the motivation behind it). The DeltaV specification only states that each VHR is assigned new distinct and unique server-defined URL. The examples in the specification suggest the usage of "auto-inc" numbers, e.g. /his/73/ver/1. So, the implementation is free in defining an appropriate pattern. We have also thought of using some other kind of unique identifier, e.g. current time in milliseconds. > Now I *personally* do think that the core API *could* be changed to > enable such functionality directly. This would be a huge change, but > maybe we should consider identifying nodes by a UID, and making the > URI a property of the revision. I haven't thought this through, just > trying to trigger a discussion. Since such a more "revolutionary" approach would have a major impact on the store API (as Remy pointed out), we opted for keeping things stable for now. But, changing the core API may be justifiable at any point of time ... I am curious about the discussion. > - Could we put the workspaces directly into the user nodes, i.e. have > "/users/john/workspace/a" instead of "/workspaces/john/a" ? > (I'll have to catch up on the whole concept of workspaces I think :P) No, because we probably would get a conflict with the semantics of the /users tree. The URI "/users/john/workspace/a" could mean that "john" is a group, "workspace" a subgroup of "john" an "a" a principal in the group "/users/john/workspace". > - Clients: what are you using to test the DeltaV implementation, the > Slide CLI client ? Yes. The extensions for DeltaV are already commited in Slide client. Regards, Peter > -----Original Message----- > From: Christopher Lenz [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 25, 2002 10:46 > To: Slide Developers List > Subject: Re: Proposal for adding DeltaV support to Slide > [more readable > now] > > > Hi Juergen, Peter, Ralf! > > First, I think it's exciting to see some movement in the > DeltaV space, > DeltaV is obviously a complex topic but it looks like you're doing a > great job. > > I have a couple of questions, but let me warn you that I haven't read > the latest DeltaV specification in detail, so some of this > might sound > a bit lame... > > - History numbers: I assume using 'auto-increment'-style numbers here > is to support renaming/moving of resources, i.e. a resource is not > tied to the name it was originally created with, as is in CVS (of > course using auto-inc numbers doesn't look totally elegant, so I'm > asking for the motivation behind it). > > I think I can see that this is the the main reason for a DeltaV > implementation not being able to directly map to the revisions- > descriptors related object model in Slide: Nodes are always > identified > by URI, so it will not be possible to maintain a history over nodes > that get renamed or moved. > > Now I *personally* do think that the core API *could* be changed to > enable such functionality directly. This would be a huge change, but > maybe we should consider identifying nodes by a UID, and making the > URI a property of the revision. I haven't thought this through, just > trying to trigger a discussion. > > Slide is still in a pretty early stage WRT to the versioning > API IMHO, > and it'd be sad if we already had to resort to workarounds > because the > API was frozen before a real implementation of a versioning-capable > front-end existed. > > - Could we put the workspaces directly into the user nodes, i.e. have > "/users/john/workspace/a" instead of "/workspaces/john/a" ? > (I'll have > to catch up on the whole concept of workspaces I think :P) > > - Clients: what are you using to test the DeltaV implementation, the > Slide CLI client ? I'm not aware of any client supporting it. I was > thinking about possible synergies with the Eclipse project: They have > a WebDAV team that is AFAICT working on a DeltaV client library, > probably based on DAV4J. > > Again, totally excited to see DeltaV happening :o) > -chris > ________________________________________________________________ > cmlenz at gmx.de > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
