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)
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Transfer-Encoding: 7bit
Message-Id: <8AFA9B39-9142-4C9C-A947-BC788F232A58@ctoforaday.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: jackrabbit-dev@incubator.apache.org
From: Gregory Block <gblock@ctoforaday.com>
Subject: On a Slide/DAV merge.
Date: Wed, 21 Dec 2005 10:34:05 +0000

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.