Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Thu, 22 Dec 2005 12:15:14 +0100
Message-Id: <2081070431@web.de>
MIME-Version: 1.0
From: Daniel Florey <daniel.florey@web.de>
To: jackrabbit-dev@incubator.apache.org
Subject: Re: On a Slide/DAV merge.
Organization: http://freemail.web.de/
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Hi,
I don't think anybody is interested in merging jackrabbit/Slide. There is no doubt about the fact that a lot of code in Slide is very confusing - even though some parts are not that bad (Lucene/DASL search...).
I still believe in WebDAV and related protocols as there are some clever people working on them since many years.
When talking about WebDAV, it is important to keep in mind that there a different scenarios why people are interested in WebDAV:

1. Content repository providers want to DAV-enable their repositories. This is why we've introduced WCK (WebDAV construction kit)  in the Slide project. There is no corresponding approach in jackrabbit as far as I know. Just to avoid cunfusion: I don't want to do marketing for Slide, but at least when talking about WebDAV, this is a requirement that is worth to keep in mind.
Many companies simply want to give the users the ability to mount their existing data / content repository using Webfolder.

2. Talk to existing WebDAV-servers. Many people don't like to hear it, but from my experience most people want to use WebDAV to talk to MS Exchange. Exchange is implementing some very specific features (Events and Search is not really using WebDAV-standards). So the Slide webdavclient is implementing these features (Transactions, Events) and is used by many people to integrate MS Exchange.
There is no corresponding approach to the webdavclient in Jackrabbit (for good reason, as Jackrabbit is implementing a content repository and not providing a WebDAV toolkit).

3. People looking for a content repository providing a WebDAV-interface. This is what Jackrabbit is for (if I got it right). 

So I'm be personally interested in supporting WebDAV, just because I think it would be great to have a standard to use different upcoming clients with different servers. The following tasks come into my mind:
1. Desiging a java WebDAV-api reflecting the different WebDAV-protocols.

2. Provide different implementations of this api for different needs:
a) Map api calls to WebDAV-requests to use it as a WebDAV-client (comparable to Slide's webdavclient)
This implementation should provide a concept for pluggable converters to for example convert DASL-search requests to MS-Exchange requests) or to enrich DeltaV-requests with subversion specific properties.
b) Map api calls to Jackrabbit
c) Companies interested in DAV-enabling their existing data can provide implementations either implementing JSR-170 or implementing the WebDAV-api. 

3. Implement a server side part to parse WebDAV-requests and map them to api calls.

We would be able to combine these parts to simply convert MS Exchange server into a WebDAV-server providing DASL-compliant search...

I have not yet had the chance to look into the DAV-interface of Jackrabbit in more detail but when I looked at it months ago it seemed to me not to provide such a generic approach (split into api/impl). But I may be wrong?
Is anybody interested in such a project? 

Cheers,
Daniel


jackrabbit-dev@incubator.apache.org schrieb am 21.12.05 11:34:48:
> 
> Okay...  I'm going to be honest and frank.  This mail will likely  
> offend.
> 
> We've been using slide - and reporting bugs, and trying to contribute  
> patches... for nigh on a year now.  Here's my critical review of how  
> that's gone.
> 
>   - It works.  That's about the best you can say for it.
>   - In order to make it work reliably, I've had to build a bunch of  
> interceptors to make it behave properly with DAV clients like GoLive  
> and Dreamweaver - clients I have to support, regardless of people's  
> personal opinions towards them.
>   - Attempts to get changes into the system end up in a bug system  
> that never gets touched.
>   - The great wheel of the release cycle has not turned on that  
> project in a long time - and with good reason.  2.1 is full of bugs  
> which are fixed in 2.2; 2.2 is full of bugs that never get fixed.  I  
> was stuck with a post-2.1 CVS release when I was on 2.1, and now I'm  
> frozen in time on a 2.2 I dare not update.
>   - The store implementation is HIDEOUS.  The code in there is awful,  
> and full of some of the worst practice code I've ever seen (speaking  
> of the XML repository, specifically.)  And the JDBC store?  Poor  
> performance and deadlocking under heavy load was so common that we've  
> reverted to the filesystem store for any kind of stability or  
> performance.
>   - Memory usage and garbage collection from Slide under moderate  
> load is bad.  By "moderate" load, I mean each page generation from  
> the application making one or more requests against the DAV server to  
> include/incorporate/etc. content into the page (e.g., using the  
> backend Slide API as a Jackrabbit repository, while using DAV  
> servlets to manage the content contained in the DAV system.)
> 
> Clustering?  An improbable design at best.
> 
> There isn't anything - ANYTHING - worth saving in that project that  
> can't be easily redone in what's already implemented in Jackrabbit's  
> DAV implementation in a cleaner and more versatile way.  There is no  
> part of the codebase worth considering for retention.
> 
> I beg - please do not merge the codebases.  Please do not think of  
> them as even being the same *kinds* of projects.  Slide, as a  
> codebase, is dead.   Slide as a project may live on in the eyes of  
> those who are using it, but only because there is no other solution.
> 
> Let there be competition - let the market decide who survives.   
> Slide, because there is no alternative, has never improved beyond its  
> current state; it has never been, in my opinion, a stable, reliable  
> product, and any efforts which have been made to correct that have  
> either been ignored or overlooked.  I do not wish to maintain, for  
> the rest of my life, a forked version of a project that I can't stand  
> working in because the design decisions made therein are half blind.
> 
> No proper testcases.  Poor parser management on the XML side.  Reams  
> of pointless data copying.  Poor transaction handling, and unreliable  
> behaviour with regards to both filesystem and database transactions.   
> I beg you not to swallow this poison pill into, up until now, a  
> project I had hoped might provide a working alternative to Slide.
> 
> Don't ask me to fix it - like another author, I don't want to be  
> involved in it anymore.  I just want to get away from it - and will  
> be perfectly happy to dedicate the company time and resources into a  
> cleaner implementation.  I have high hopes for the DAV server  
> implementation, as it stands, in Slide; not so happy with the deploy  
> mechanism, as I'd hoped for replication on day one, but hey, that's  
> life, and it's not like I can pretend that Slide's current mechanism  
> is a dream come true.  A switch tomorrow to Jackrabbit - which will  
> start the day that Jackrabbit 1.0 is released - will be a dream come  
> true and rid us of the horrible nightmare that our current DAV  
> implementation in Slide has been to date.
> 
> It isn't worth saving, in my opinion.  Let them go top level - but  
> don't you dare integrate the codebase into an implementation that has  
> the potential that the current one has.
> 
> 
> The arguments I've seen to date over the 'intention' of the current  
> DAV implementation is unfortunate - I, too, don't see a problem with  
> making it extensible.  On our side, we're going to need to implement  
> a variety of actions which take place upon content as it is acted  
> upon by clients - extracting additional metadata from images as they  
> are modified, as an example; and no doubt others will have similar  
> requirements.  Making use of the DAV portion as a file-based view is  
> all well and good, but when it comes to actually incorporating the  
> DAV capabilities into the Jackrabbit system we're deploying as the  
> core parts of our system, we'll need to be able to act on the content  
> as it passes through.  I am, therefore, in favor of either modifying  
> the current implementation with the ideas on extensibility that Brian  
> Moseley is requesting, and that Angela disagrees with.
> 
> Which is odd; because although I can see Angela's point - that the  
> purpose of the DAV implementation is to provide a simple file-based  
> view of its contents - I fall more into Moseley's opinion:  that  
> fundamentally, real-world usage of this system will demand that  
> integrators who wish to make use of the DAV functionality provided as  
> a part of that server will need to be able to tightly couple DAV  
> operations into their application's problem domain and specific  
> requirements.  While I like Angela's point and goal, I don't believe  
> it actually fills the real-world need that most people who go to  
> integrate this thing will actually need.
> 
> So if Moseley wants to take the current DAV implementation, copy it  
> off into contrib, and start making modifications to it so that it's  
> more extensible, that sounds like a winner to me.  That fits *my*  
> needs for the product - a DAV implementation that's lightweight but  
> allows enough customisation to allow us to do the things that the  
> business needs to happen to that data on the way in - extracting  
> metadata from ingested content as it passes into the system, or  
> making necessary modifications as content is modified through the DAV  
> interface.
> 
> I apologise for butting in - to be honest, had this whole issue of  
> 'adopting' Slide not come up, I'd never have said a word on it.  But  
> I can't let that pass - and I beg you not to take that action.  I  
> know, deep in my heart, that there are others from us here who have  
> come from the Slide community not as a traveller but as a refugee -  
> and my fellow refugees will likely stand with me on this.  I hope.


______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193