> Hi, > > We would like to add DeltaV support to Slide. In the following, based on > experiences we gained with a prototype, we would like to sketch our > first thoughts for doing so. > > Since the following is a bit lengthy, here is a summary: > > - We want to integrate DeltaV with the existing versioning in Slide as > much as possible. > - In our opinion, a fully integrated solution is *not* possible without > extensive changes to the Slide core layer (API, helpers). The semantics > of the Slide API would need to move towards DeltaV by refactoring the > existing types and adding new ones. > - But ... we would prefer to change as less as possible the current > architecture of Slide and therefore we will propose a "semi-integrated" > solution. > - Most of the work will be in the WebDAV layer (servlet, method > implementations). We will need to implement the new DeltaV methods and > also the current (non-DeltaV) method implementations will need some > adaptations. > - For the beginning we are *not* considering the advanced features of > DeltaV.
I agree with all of the above. Not going with all the advanced features at first is fine since: - it will reduce development time - most users are primarily interested in basic versioning - most if not all clients will only support basic versioning, at least for some time > On request, our prototype is available by email. It's great to hear that you already have a working prototype. Feel free to send it to my personal email address @apache. Thanks ! To summarize, your explanations are correct. The locks currently would apply to all revisions, and same for the permissions, so that's the main problem with the core API you have to solve. Obviously, it was a lot simpler to implement it that way. Another way around is to be more revolutionary, and to map 1 revision <-> 1 resource the way Delta V does (with an extra resource being the resivion descriptors, aka the revision tree info). Maybe it's wiser to limit the amount of changes as much as possible, though (unlike your solution, this solution would have a bigger impact on the store API, which is the thing which should be kept as stable as possible). Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
