incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nuescheler <>
Subject Re: Idea of JCMS
Date Mon, 01 Nov 2004 11:56:43 GMT
hi oli,

thanks for your comments. i really appreciate your interest.

> first of all let me say that I really appreciate your help! Second,
> let me say that I have no reservations concerning Jackrabbit and
> certainly do not see it as a threat to Slide or the other way round
> (which others seemed to feel in other posts), but rather want to
> explore where each project can learn from the other or where they
> could combine efforts or benefit from each other - like with sharing a
> WebDAV implementation.
agreed. i certainly would be great to share a webdav library 
for example.

> > > (1) Where can I get the (tentative) JCR API?
> > you can download the snapshot that was out for public review
> > in may-2004
> > ( )
> > which is a quite a bit outdated now. or you can get the binaries that
> > are used by maven to build for jackrabbit from
> > "proposed final draft" will be submitted soon (i hope).
> Thanks, got it now! Is this the API you were programming Jackrabbit to?
precisely... the versions of the jcr.jar (v0.15) are in sync with the
versions of the spec. 

> > > (2) When *presumably* will Jackrabbit be mature enought
> > > to be an alternative to the current Slide backend?
> > since i do not know slide well enough to understand how
> > mature it is and i cannot judge what it would mean to be an alternative
> > to the slide backend, i can only speak for jackrabbit. even when
> > jackrabbit was still a slide proposal people (unfortuntately)
> > started to use it in production.
> Which is not your fault!
which is other peoples fault, and they know that the
have to live with the continous changes, in the api.

> > there are already mature applications that are built
> > uniquely on jackrabbit, so far people have been very
> > happy with the stability.
> That's great! Do you have links to them?
sure... i think one of the earliest adopters you can find for example 

> I suppose this is without authentication, access rights management and
> locking, right?
well, not entirely. but it is correct that currently locking and access control
are currently still being developed. but applications can most certainly
deal with those topics themselves, which i would (as i mentioned 
before) not suggest.

> Please forbear with me as I am not yet familiar with Jackrabbit, but
> as far as I have seen there is only a backend to the file system and
> none to a relational database, right? Or have I missed something?
there could be a wide variety of PerstistenceManagers that people
could think of. personally, i believe that an fs backend certainly has
great value when it comes to ease of deployment, but as you might 
see on the jackrabbit list other people are already discussing jdbc
contributions... we will see...

> How does the JCRQL look like? Is there any link to documentation?
see the spec that you downloaded ;) 
however, it is subject to change.

> > i am sure there are very different mechanisms to measure
> > robustness, which are usually very dependant on the
> > requirements of the users. do you have any sort of
> > performance metrics in mind? uptime? size of the
> > repository in bytes or nodes (resources)? transactions
> > per second? functionality (versioning, query,
> > transactions,...?)? memory consumption?
> Bottom line is Jackrabbit is something you would advice to program to
> for production? Even now? Well, that's good news for me! Why not
> moving it out of the incubator then?
first of all the criteria for moving something out of the 
incubator is has nothing to do with the stability of the code,
but with the maturity of a project from a community perspective.
from that perspective jackrabbit certainly still belongs into
the incubator, we are still a very young community.

as the spec-lead i would of course discourage anybody from 
using jsr-170 until it is finally approved by the executive 
committee of the jcp unless they are willing to accept the 
consequences of continuous change of the api.

of course personally as a developer i would refuse to
work with anything else but jsr-170 when it comes to
communicating with a content repository, and i much 
rather incurr the impact of continuous changes in 
the jsr-170, than having to deal with a proprietary api.

thanks again for all the excellent questions.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message