Slide 3.0 design approach

[Daniel Florey <da...@web.de>]

Slide 3.0

=======

 

Slide 3.0 will be the next major step in the evolution of the jakarta
WebDAV-server.

This thread shall be used to discuss the overall design approach of the 3.0
release.

 

Main goals for Slide 3.0 Server:

 

* Separation and clarification of the different layers regarding design and
implementation

Currently the layers are mixed up, especially versioning is hacked into
WebDAV-layer and not available at kernel layer.

The same with ACL implementation.

 

* Full support of DeltaV-features

Versioning is currently working in Slide, but is not ready to replace
existing VCS's. Beside the missing features 

(Activities, Configurations, Baselines etc.), the main disadvantage of the
current implementation is, that the complete document is stores for each
version. We need content type specific pluggable diffs, so that a huge
number of documents can be managed in Slide without causing headache.

We should work together with the Subversion-team to make Slide and
Subversion WebDAV-compliant. There are some very promising Subversion
clients (Subclipse, SVNup, TortoiseSVN...). It would really nice if they
would work with Slide.

 

* Support of exchange specific WebDAV-methods

In order to achieve exchange compliance regarding the WebDAV interface, we
need some significant changes. 

So why should we support all the Microsoft-specific extension, that are not
yet WebDAV-standard? There are at least two good reasons:

The first: Microsoft had some good reasons to implement this extensions, as
they adress some areas where no WebDAV draft is available: Notofications,
Transactions and Batch-methods. It would be nice, to have this features in
Slide as well.

Second: As exchange is supporting WebDAV and there are already some client,
using this interface to build PIM applications on top of it (have a look at
Evolution or Outlook Web Access for example), it would be a great thing if
this clients would be able to talk to Slide as well.

Think of a Slide backed CMS-application, where task management can be
handled by using Outlook/Evolution.

Notifications and transactions will hopefully make it into Slide 2.x and we
have to evaluate if OWA or Evolution also use Batch-methods.

The most important and most difficult part will be, to implement the
Microsoft-specific query language.

We need to map different search syntaxes to the internal search engine.
Additionally, we have to implement the Range-header extension.

 

* Allow easy integration of existing repositories

It is already possible to build custom stores, to access legacy systems via
the Slide server.

What we need is a multi-layer store approach, enable to integrate different
types of legacy repositories:

Some of them provide transactions (RDBMS), others don't. Some provide search
capabilities (filesystem?), versioning (CVS), ACL (filesystem) etc.

So it would be nice to have some kind of generic store implementation, that
provides all of this features and you can use them, if the legacy repository
doesn't support a particular feature.

Think of this: You want use LDAP as a user database. LDAP doesn't support
transactions as far as I know. Wouldn't it be nice, if we could use the
generic store to handle transactions (based on tx filestore) and store them
into LDAP at commit time. So this would allow to add several users in a
single transaction and rollback or commit them as a single unit.

The same with ACL and other Slide features.

This is somehow comparable to a software implementation of OpenGL, that can
be replaced by using native drivers instead.

To achieve this, we need to redesign the general design approach as stated
above.

 

* Unifiy client and server java API

Currently there are at least two totally separate API's to access the
repository:

The webdavclient API on client side and the Slide API on the server side.
Beside the fact, that the server API is currently broken (as API-created
versions are not accessible via DeltaV).

It would be a great benefit, if we could manage to have the same API at
client and server side. So a java client could use this API to access Slide
and could be deployed on the same machine (using Server side implementation)
or remote (using client side impl).

 

The big picture:

 

Overview of proposed Slide server 3.0 layers:

 

== Remote client layer (Slide API) ==

The remote client layer will be provide a client API that can be used to
connect to a full featured WebDAV-server. The implementation uses
webdavclient-lib to connect to the server.

 

== WebDAV-layer ==

The WebDAV layer handles the requests and wraps them into the matching
API-call. This layer simply consist of the well known WebDAV-servlet and the
-helpers. All logic that is implemented into the WebDAV-methods should be
moved into Slide kernel layer.

 

== Unification layer (Slide API) ==

The Slide API represents the WebDAV-protocols at java level. Each
WebDAV-method has corresponding java methods. This will mostly look like the
current webdavclient implementation, but without all of the HTTP-stuff.

This layer is responsible for dispatching requests to the different mounted
stores. It is not responsible for any application logic. This is done by the
stores. So if we have another Slide server running that shall be mounted as
a Slide store, this can be done easily as it provides the whole set of
required methods.

The unification layer provides some services that are necessary to allow
unification:

User/group management: Need to collect the users and roles from different
stores

Transaction management: Handle distributes transactions for all
participating stores

ACL management: ...

 

== Store layer (Slide API) ==

The store layer uses the same API as the dispatching layer! So if for
example a full featured WebDAV-server will be used as store, this can be
easily done by using the Slide API (client side implementation).

The generic store provides all features based on the tx filesystem.
Different adaptors can be implemented to replace generic implementation with
native store implementation. If we want to mount the exchange server, we can
replace notifications, read/write, locks and transactions with native
implementations and keep the versioning from the generic store
implementation. So we could easily make exchange versioning aware!

 

Scenario 1: Client and server on the same machine:

 

Client -> Slide API (server side impl) -> Stores

 

Scenario 2: Client and server on different machines:

 

Client -> Slide API (client side impl) -> WebDAV -> | WebDAV-layer -> Slide
API (server side impl) -> Stores

 

Any comments are welcome!

 

Cheers,

Daniel

Re: Slide 3.0 design approach

[Stefan Lützkendorf <lu...@apache.org>]

An other point I think we should consider.

Slide was originally designed to have multiple namespaces
in a single domain (and so in a single vm).

If we decide to maintain this feature we have to take care
about where to place configuration parameters. Currently
we have deltav and event settings in the domain configuration.

But if we have multiple namespaces there migth be the need to
configure them differently.

So I think some of theses parameters should move to namespace
configuration.

Perhaps this could be done at any of the next 2.x releases
because it is not such a big change than the important layer
separation proposed by Daniel.

Regards Stefan.


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org

RE: Slide 3.0 design approach

[Michael Oliver <ol...@matrix-media.com>]

-----Original Message-----
From: Paul Hussein [mailto:paul.hussein@jrc.it] 
Sent: Monday, June 14, 2004 12:35 AM
To: Slide Developers Mailing List
Subject: RE: Slide 3.0 design approach




Can I put my two penneth in.
[Mike Oliver>>] me too

Authentication

I believe one of the most important thinbgs, if Slide is to be used in
the
enterprise is to have out of the box authentication against LDAP (
Including
Active Directory ).
There is of course JAAS which many projects seem to be using for
authentication.

[Mike Oliver>>] +1

GUI File Selection
Slide ( WebDAV API ) could do with a JFileChooser.

[Mike Oliver>>] +1 but I see you already contributed one.

Testing

Slide needs improved testing. Currently it does not work with the WebDAV
client implementation in Mac OSX. Testing with as many tools as possible
and
as Daniel rightly says, as much testing and integration work as possible
with Microsoft and the Open Groupware and Evolution teams as possible,
to
make Slide WebDAV the most compatible and widely used implementation.


[Mike Oliver>>] +1 


Thats my thoughts anyway.






> -----Original Message-----
> From: daniel.florey@web.de [mailto:daniel.florey@web.de]
> Sent: Sunday, June 13, 2004 12:19 PM
> To: Slide Developers Mailing List
> Subject: Slide 3.0 design approach
>
>
> Slide 3.0
>
> =======
>
>
>
> Slide 3.0 will be the next major step in the evolution of the jakarta
> WebDAV-server.
>
> This thread shall be used to discuss the overall design approach
> of the 3.0
> release.
>
>
>
> Main goals for Slide 3.0 Server:
>
>
>
> * Separation and clarification of the different layers regarding
> design and
> implementation
>
> Currently the layers are mixed up, especially versioning is hacked
into
> WebDAV-layer and not available at kernel layer.
>
> The same with ACL implementation.
>
>
>
> * Full support of DeltaV-features
>
> Versioning is currently working in Slide, but is not ready to replace
> existing VCS's. Beside the missing features
>
> (Activities, Configurations, Baselines etc.), the main disadvantage of
the
> current implementation is, that the complete document is stores for
each
> version. We need content type specific pluggable diffs, so that a huge
> number of documents can be managed in Slide without causing headache.
>
> We should work together with the Subversion-team to make Slide and
> Subversion WebDAV-compliant. There are some very promising Subversion
> clients (Subclipse, SVNup, TortoiseSVN...). It would really nice if
they
> would work with Slide.
>
>
>
> * Support of exchange specific WebDAV-methods
>
> In order to achieve exchange compliance regarding the WebDAV
interface, we
> need some significant changes.
>
> So why should we support all the Microsoft-specific extension,
> that are not
> yet WebDAV-standard? There are at least two good reasons:
>
> The first: Microsoft had some good reasons to implement this
> extensions, as
> they adress some areas where no WebDAV draft is available:
Notofications,
> Transactions and Batch-methods. It would be nice, to have this
features in
> Slide as well.
>
> Second: As exchange is supporting WebDAV and there are already
> some client,
> using this interface to build PIM applications on top of it (have
> a look at
> Evolution or Outlook Web Access for example), it would be a great
thing if
> this clients would be able to talk to Slide as well.
>
> Think of a Slide backed CMS-application, where task management can be
> handled by using Outlook/Evolution.
>
> Notifications and transactions will hopefully make it into Slide
> 2.x and we
> have to evaluate if OWA or Evolution also use Batch-methods.
>
> The most important and most difficult part will be, to implement the
> Microsoft-specific query language.
>
> We need to map different search syntaxes to the internal search
engine.
> Additionally, we have to implement the Range-header extension.
>
>
>
> * Allow easy integration of existing repositories
>
> It is already possible to build custom stores, to access legacy
> systems via
> the Slide server.
>
> What we need is a multi-layer store approach, enable to integrate
> different
> types of legacy repositories:
>
> Some of them provide transactions (RDBMS), others don't. Some
> provide search
> capabilities (filesystem?), versioning (CVS), ACL (filesystem) etc.
>
> So it would be nice to have some kind of generic store
> implementation, that
> provides all of this features and you can use them, if the legacy
> repository
> doesn't support a particular feature.
>
> Think of this: You want use LDAP as a user database. LDAP doesn't
support
> transactions as far as I know. Wouldn't it be nice, if we could use
the
> generic store to handle transactions (based on tx filestore) and
> store them
> into LDAP at commit time. So this would allow to add several users in
a
> single transaction and rollback or commit them as a single unit.
>
> The same with ACL and other Slide features.
>
> This is somehow comparable to a software implementation of
> OpenGL, that can
> be replaced by using native drivers instead.
>
> To achieve this, we need to redesign the general design approach as
stated
> above.
>
>
>
> * Unifiy client and server java API
>
> Currently there are at least two totally separate API's to access the
> repository:
>
> The webdavclient API on client side and the Slide API on the server
side.
> Beside the fact, that the server API is currently broken (as
API-created
> versions are not accessible via DeltaV).
>
> It would be a great benefit, if we could manage to have the same API
at
> client and server side. So a java client could use this API to
> access Slide
> and could be deployed on the same machine (using Server side
> implementation)
> or remote (using client side impl).
>
>
>
> The big picture:
>
>
>
> Overview of proposed Slide server 3.0 layers:
>
>
>
> == Remote client layer (Slide API) ==
>
> The remote client layer will be provide a client API that can be used
to
> connect to a full featured WebDAV-server. The implementation uses
> webdavclient-lib to connect to the server.
>
>
>
> == WebDAV-layer ==
>
> The WebDAV layer handles the requests and wraps them into the matching
> API-call. This layer simply consist of the well known
> WebDAV-servlet and the
> -helpers. All logic that is implemented into the WebDAV-methods should
be
> moved into Slide kernel layer.
>
>
>
> == Unification layer (Slide API) ==
>
> The Slide API represents the WebDAV-protocols at java level. Each
> WebDAV-method has corresponding java methods. This will mostly
> look like the
> current webdavclient implementation, but without all of the
HTTP-stuff.
>
> This layer is responsible for dispatching requests to the
> different mounted
> stores. It is not responsible for any application logic. This is
> done by the
> stores. So if we have another Slide server running that shall be
> mounted as
> a Slide store, this can be done easily as it provides the whole set of
> required methods.
>
> The unification layer provides some services that are necessary to
allow
> unification:
>
> User/group management: Need to collect the users and roles from
different
> stores
>
> Transaction management: Handle distributes transactions for all
> participating stores
>
> ACL management: ...
>
>
>
> == Store layer (Slide API) ==
>
> The store layer uses the same API as the dispatching layer! So if for
> example a full featured WebDAV-server will be used as store, this can
be
> easily done by using the Slide API (client side implementation).
>
> The generic store provides all features based on the tx filesystem.
> Different adaptors can be implemented to replace generic
> implementation with
> native store implementation. If we want to mount the exchange
> server, we can
> replace notifications, read/write, locks and transactions with native
> implementations and keep the versioning from the generic store
> implementation. So we could easily make exchange versioning aware!
>
>
>
> Scenario 1: Client and server on the same machine:
>
>
>
> Client -> Slide API (server side impl) -> Stores
>
>
>
> Scenario 2: Client and server on different machines:
>
>
>
> Client -> Slide API (client side impl) -> WebDAV -> |
> WebDAV-layer -> Slide
> API (server side impl) -> Stores
>
>
>
> Any comments are welcome!
>
>
>
> Cheers,
>
> Daniel
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org

RE: Slide 3.0 design approach

[Paul Hussein <pa...@jrc.it>]

Can I put my two penneth in.


Authentication

I believe one of the most important thinbgs, if Slide is to be used in the
enterprise is to have out of the box authentication against LDAP ( Including
Active Directory ).
There is of course JAAS which many projects seem to be using for
authentication.


GUI File Selection
Slide ( WebDAV API ) could do with a JFileChooser.


Testing

Slide needs improved testing. Currently it does not work with the WebDAV
client implementation in Mac OSX. Testing with as many tools as possible and
as Daniel rightly says, as much testing and integration work as possible
with Microsoft and the Open Groupware and Evolution teams as possible, to
make Slide WebDAV the most compatible and widely used implementation.




Thats my thoughts anyway.






> -----Original Message-----
> From: daniel.florey@web.de [mailto:daniel.florey@web.de]
> Sent: Sunday, June 13, 2004 12:19 PM
> To: Slide Developers Mailing List
> Subject: Slide 3.0 design approach
>
>
> Slide 3.0
>
> =======
>
>
>
> Slide 3.0 will be the next major step in the evolution of the jakarta
> WebDAV-server.
>
> This thread shall be used to discuss the overall design approach
> of the 3.0
> release.
>
>
>
> Main goals for Slide 3.0 Server:
>
>
>
> * Separation and clarification of the different layers regarding
> design and
> implementation
>
> Currently the layers are mixed up, especially versioning is hacked into
> WebDAV-layer and not available at kernel layer.
>
> The same with ACL implementation.
>
>
>
> * Full support of DeltaV-features
>
> Versioning is currently working in Slide, but is not ready to replace
> existing VCS's. Beside the missing features
>
> (Activities, Configurations, Baselines etc.), the main disadvantage of the
> current implementation is, that the complete document is stores for each
> version. We need content type specific pluggable diffs, so that a huge
> number of documents can be managed in Slide without causing headache.
>
> We should work together with the Subversion-team to make Slide and
> Subversion WebDAV-compliant. There are some very promising Subversion
> clients (Subclipse, SVNup, TortoiseSVN...). It would really nice if they
> would work with Slide.
>
>
>
> * Support of exchange specific WebDAV-methods
>
> In order to achieve exchange compliance regarding the WebDAV interface, we
> need some significant changes.
>
> So why should we support all the Microsoft-specific extension,
> that are not
> yet WebDAV-standard? There are at least two good reasons:
>
> The first: Microsoft had some good reasons to implement this
> extensions, as
> they adress some areas where no WebDAV draft is available: Notofications,
> Transactions and Batch-methods. It would be nice, to have this features in
> Slide as well.
>
> Second: As exchange is supporting WebDAV and there are already
> some client,
> using this interface to build PIM applications on top of it (have
> a look at
> Evolution or Outlook Web Access for example), it would be a great thing if
> this clients would be able to talk to Slide as well.
>
> Think of a Slide backed CMS-application, where task management can be
> handled by using Outlook/Evolution.
>
> Notifications and transactions will hopefully make it into Slide
> 2.x and we
> have to evaluate if OWA or Evolution also use Batch-methods.
>
> The most important and most difficult part will be, to implement the
> Microsoft-specific query language.
>
> We need to map different search syntaxes to the internal search engine.
> Additionally, we have to implement the Range-header extension.
>
>
>
> * Allow easy integration of existing repositories
>
> It is already possible to build custom stores, to access legacy
> systems via
> the Slide server.
>
> What we need is a multi-layer store approach, enable to integrate
> different
> types of legacy repositories:
>
> Some of them provide transactions (RDBMS), others don't. Some
> provide search
> capabilities (filesystem?), versioning (CVS), ACL (filesystem) etc.
>
> So it would be nice to have some kind of generic store
> implementation, that
> provides all of this features and you can use them, if the legacy
> repository
> doesn't support a particular feature.
>
> Think of this: You want use LDAP as a user database. LDAP doesn't support
> transactions as far as I know. Wouldn't it be nice, if we could use the
> generic store to handle transactions (based on tx filestore) and
> store them
> into LDAP at commit time. So this would allow to add several users in a
> single transaction and rollback or commit them as a single unit.
>
> The same with ACL and other Slide features.
>
> This is somehow comparable to a software implementation of
> OpenGL, that can
> be replaced by using native drivers instead.
>
> To achieve this, we need to redesign the general design approach as stated
> above.
>
>
>
> * Unifiy client and server java API
>
> Currently there are at least two totally separate API's to access the
> repository:
>
> The webdavclient API on client side and the Slide API on the server side.
> Beside the fact, that the server API is currently broken (as API-created
> versions are not accessible via DeltaV).
>
> It would be a great benefit, if we could manage to have the same API at
> client and server side. So a java client could use this API to
> access Slide
> and could be deployed on the same machine (using Server side
> implementation)
> or remote (using client side impl).
>
>
>
> The big picture:
>
>
>
> Overview of proposed Slide server 3.0 layers:
>
>
>
> == Remote client layer (Slide API) ==
>
> The remote client layer will be provide a client API that can be used to
> connect to a full featured WebDAV-server. The implementation uses
> webdavclient-lib to connect to the server.
>
>
>
> == WebDAV-layer ==
>
> The WebDAV layer handles the requests and wraps them into the matching
> API-call. This layer simply consist of the well known
> WebDAV-servlet and the
> -helpers. All logic that is implemented into the WebDAV-methods should be
> moved into Slide kernel layer.
>
>
>
> == Unification layer (Slide API) ==
>
> The Slide API represents the WebDAV-protocols at java level. Each
> WebDAV-method has corresponding java methods. This will mostly
> look like the
> current webdavclient implementation, but without all of the HTTP-stuff.
>
> This layer is responsible for dispatching requests to the
> different mounted
> stores. It is not responsible for any application logic. This is
> done by the
> stores. So if we have another Slide server running that shall be
> mounted as
> a Slide store, this can be done easily as it provides the whole set of
> required methods.
>
> The unification layer provides some services that are necessary to allow
> unification:
>
> User/group management: Need to collect the users and roles from different
> stores
>
> Transaction management: Handle distributes transactions for all
> participating stores
>
> ACL management: ...
>
>
>
> == Store layer (Slide API) ==
>
> The store layer uses the same API as the dispatching layer! So if for
> example a full featured WebDAV-server will be used as store, this can be
> easily done by using the Slide API (client side implementation).
>
> The generic store provides all features based on the tx filesystem.
> Different adaptors can be implemented to replace generic
> implementation with
> native store implementation. If we want to mount the exchange
> server, we can
> replace notifications, read/write, locks and transactions with native
> implementations and keep the versioning from the generic store
> implementation. So we could easily make exchange versioning aware!
>
>
>
> Scenario 1: Client and server on the same machine:
>
>
>
> Client -> Slide API (server side impl) -> Stores
>
>
>
> Scenario 2: Client and server on different machines:
>
>
>
> Client -> Slide API (client side impl) -> WebDAV -> |
> WebDAV-layer -> Slide
> API (server side impl) -> Stores
>
>
>
> Any comments are welcome!
>
>
>
> Cheers,
>
> Daniel
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org