> Hello, > > Thanks for the interest in Delta-V. > We (Software AG) are volunteering for a Delta-V implementation in Slide. > If you agree, we have following plan: > Our time frame would be, to have the Delta-V standard at least partly > implemented until mid of 2002 (including workspaces). > Currently we are implementing a prototype, to find out basic concepts and > the areas in Slide, which we need to touch for a Delta-V implementation.
It's quite obvious that the "content" package will have to go through some changes. > We will share this information (design and code) with you next week. Sounds good to me. > Our plan is to proceed with the prototype towards a working version, which > shows most of the concepts and their possible architecture and > implementation, again publish the results in the Slide community. > In parallel we will prepare the final architecture (based on the prototype > results) and ask for feed-back (this phase should be completed until end of > this year). Then the final implementation will start for all associated > layers (client API, servlet, CM Api, stores etc.). Possibly this will be an > iterating process. Yes. > We will be very happy, when additional people are volunteering to help us in > this big task (e.g. Jiantao Pan expressed her/his interest in testing, Remy > and Dierk in the kernel, etc.). Obviously, I'll help. I'll also be experimenting with the core if I can, to try to make it workflow based. If I have the time to do it, it will happen as an independent proposal (since it will be considered highly experimental; I'll add a "proposals" directory for this). The goals are to: - be compatible (or at worst require little changes) with the current Slide API from the WebDAV servlet perspective - be compatible with the current stores - add approvals / confirmations / preconditions, which should provide a lot of flexibility to extend the processing of commands - add indexing (probably using the workflow-like capabilities mentioned above), as well as a searching interface - be a bit faster than the current core by avoiding some redundant operations (mainly security and lock checks) One thing I was also considering which would require an important API change is strenghtening a lot the notion of ownership, by adding an 'owner' field on the node (as a property, it's very hard to access it easily from the security layer, and it's also very hard to treat it as a special protected property). > We will prepare a task list (completed end > of 2001), where people can volunteer themselves. Especially in the store > areas (file and JDBC) we are happy for helper, but also in all other areas. > Does this make sense? Yes, that's great :) Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
