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 > > ( http://jcp.org/aboutJava/communityprocess/review/jsr170/index.html ) > > which is a quite a bit outdated now. or you can get the binaries that > > are used by maven to build for jackrabbit from http://www.day.com/maven/ > > "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 at http://www.magnolia.info > 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. regards, david --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
