You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Sanjiva Weerawarana <sa...@opensource.lk> on 2004/11/01 02:24:57 UTC
Re: Idea of JCMS
"Rolf Kulemann" <ro...@apache.org> writes:
>
> But JCMS also claims to support/use standards like JCR. AFAICS Slide
> does not support JCR. I do not know why, but I saw some posting giving
> me the feeling it was due to lack of collaboration between the former
> jcrri team and the Slide team.
I don't know the scope of these projects but ...
If the only problem is that Slide doesn't support a standard (that
presumably came after its inception) then I think the right thing to do
is to go and implement that standard on top of the existing codebase.
Is there some technical reason why that can't be done? If not we're not
living up to the community building spirit by creating, in effect, a
community which is designed to kill an existing community.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Idea of JCMS
Posted by David Nuescheler <da...@gmail.com>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Idea of JCMS
Posted by Oliver Zeigermann <ol...@gmail.com>.
Hi David,
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.
More comments inline...
On Mon, 1 Nov 2004 10:44:12 +0100, David Nuescheler
<da...@gmail.com> wrote:
> hi oliver,
>
> > (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?
> > (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!
> 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?
I suppose this is without authentication, access rights management and
locking, right?
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?
How does the JCRQL look like? Is there any link to documentation?
> 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?
> if there are any standard loadtests that are used
> for slide i am sure we could port them over to
> jsr-170 and see how jackrabbit compares today...
> (which as a side effect would allow us to have
> the worlds first "general purpose content
> repository benchmark" that would run against
> any jsr-170 compliant repository ;) )
No idea how this might look like...
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Idea of JCMS
Posted by David Nuescheler <da...@gmail.com>.
hi oliver,
> (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).
i think you bring up a good point, we should somehow
manage to get the java-doc of the jsr-170 into the
jackrabbit api doc.
> (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.
there are already mature applications that are built
uniquely on jackrabbit, so far people have been very
happy with the stability.
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?
if there are any standard loadtests that are used
for slide i am sure we could port them over to
jsr-170 and see how jackrabbit compares today...
(which as a side effect would allow us to have
the worlds first "general purpose content
repository benchmark" that would run against
any jsr-170 compliant repository ;) )
david
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Idea of JCMS
Posted by Oliver Zeigermann <ol...@gmail.com>.
Two (maybe dumb) questions
(1) Where can I get the (tentative) JCR API?
(2) When *presumably* will Jackrabbit be mature enought to be an
alternative to the current Slide backend?
Oliver
On Sun, 31 Oct 2004 17:41:49 -0800, Roy T. Fielding <fi...@gbiv.com> wrote:
> There is no problem. There is no reason at all for any one project
> to "own" the CMS space at Apache. It makes sense for Slide to replace
> its back-end with Jackrabbit for one and only one reason: such an
> architecture will enable substitutability of its back-end and simplify
> Slide's implementation. If that does not turn out to be the case,
> then none of us would want Slide to use Jackrabbit and I see no
> reason to badger them into doing so. Likewise for Lenya, JCMS,
> and whatever else may come next.
>
> What we would like to see is all of the folks who think they might
> need a JVM storage management interface to get involved in the
> Jackrabbit project, try to use it to build useful things, tell us
> all when problems are encountered (preferably right now, while the
> JCR specification is still easy to change), and through that
> interaction make Jackrabbit something more useful than just another
> JSR interface. That is a heck of a lot more useful than just waiting
> to see what code the current project developers turn out.
>
> ....Roy
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Idea of JCMS
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
There is no problem. There is no reason at all for any one project
to "own" the CMS space at Apache. It makes sense for Slide to replace
its back-end with Jackrabbit for one and only one reason: such an
architecture will enable substitutability of its back-end and simplify
Slide's implementation. If that does not turn out to be the case,
then none of us would want Slide to use Jackrabbit and I see no
reason to badger them into doing so. Likewise for Lenya, JCMS,
and whatever else may come next.
What we would like to see is all of the folks who think they might
need a JVM storage management interface to get involved in the
Jackrabbit project, try to use it to build useful things, tell us
all when problems are encountered (preferably right now, while the
JCR specification is still easy to change), and through that
interaction make Jackrabbit something more useful than just another
JSR interface. That is a heck of a lot more useful than just waiting
to see what code the current project developers turn out.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org