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
