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.
