You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by "Pill, Juergen" <Ju...@softwareag.com> on 2001/11/16 17:58:53 UTC

Delta V planing

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.
We will share this information (design and code) with you next week.
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.
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.). 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? 
Best regards
Juergen Pill


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Delta V planing

Posted by Remy Maucherat <re...@apache.org>.
> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>