Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43A98B71.4080003@apache.org>
Date: Wed, 21 Dec 2005 09:05:53 -0800
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
User-Agent: Thunderbird 1.5 (Macintosh/20051025)
MIME-Version: 1.0
To: jackrabbit-dev@incubator.apache.org
Subject: Re: On a Slide/DAV merge.
References: <8AFA9B39-9142-4C9C-A947-BC788F232A58@ctoforaday.com>
In-Reply-To: <8AFA9B39-9142-4C9C-A947-BC788F232A58@ctoforaday.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Gregory Block wrote:
> 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.

Here's my opinion: the value of an apache project is its community, not 
the code. Code can be fixed *waaay* more easily than any personal issue 
or personal opinion (that, yes, can be changed by not by means of a svn 
commit).

I'm a Slide committer. At one point, I wanted to work on Slide to clean 
up the webdav part, disconnect the store and attach jackrabbit (at that 
time JCRRI, that was living inside the slide repository). I honestly 
didn't spend much time on it, but it was not trivial.

Then my life moved me away from content management and I lost interest.

Handling the HTTP side of things is 20% of the work of a good WebDAV 
solution. Ask the subversion people about that.

I've tried to upload an image on Cosmo account via webdavfs mounting on 
my mac. didn't work. this is because everytime the macosx finder sends 
requests, it does something like this

  writes .DS_Store
  writes .filename.ext
  copies .filename.ext into filename.ext
  removes .filename.ext

JackRabbit needs to be able to handle all that. WebDAV interoperability 
is a nightmare and Slide is far ahead of JackRabbit on that front.

But should we integrate or simply learn from the code?

I honestly don't care, whatever it's easier and it seems to be that 
since there is a community of interested people here, probably an 
independent effort is easy to manage and avoids a lot of political 
discussions.

-- 
Stefano.