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.
