-----Original Message----- From: Paul Hussein [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
