Michael Wechner wrote:
Andreas Hartmann wrote:
[...]
But that should be possible using a generic JCR browser
or editing tool. IMO this argument is not sufficient for
providing a filesystem-based implementation (which requires
maintenance).
everything needs maintenance ;-) So why did you start a(nother) generic
API in the first place and not use JCR directly within your suggested
API ;-)
For the following reasons:
- clarity (model exactly what the repository should be capable of)
- ease of use (reduce flexibility)
- protection (don't allow to tinker with the repository content directly)
very good reasons, but this doesn't prohibit to do a FS implementation
of the API
Yes. I'm not against the existence of a FS implementation, I'd just
like to have a stable JCR-based implementation, and I won't manage
to finish that on my own.
We once agreed on a JCR-only approach. I don't want to start
the discussion again,
I would, because I have realized there are still a lot of
people wanting to use the FS and I think it makes a lot
of sense in many cases and that's the situation many people are
in.
As said before we don't have any clue what problems lie ahead re JCR
and although I am big fan of JCR and keep pushing it for some years now,
I still want an alternative and Lenya is able to provide such an
alternative
very easily.
I doubt that we can provide it "very easily", but this depends
on one's point of view what it should be capable of.
this is why one introduces compliance levels, just as
JCR has
I'm rather refering to stability, performance, and scalability.
I just wanted to point out the option
of implementing a file-system based repository (I'm sure that
would have been the next question). The (in)famous phrase
"feel free to implement this" applies,
maybe you don't have to implement this, but please give other people
the freedom to do so, especially if they are ready to invest
the time and already invested a lot of time into this project.
Agreed. I just expressed my priorities.
but IMO we should focus
on the JCR-based implementation to end up with a stable and
performant product after a reasonable timespan.
what is a reasonable timespan? Didn't we want to release 1.4 last
autumn?
Maybe we should release ASAP
well, I think as long as we haven't removed all
direct FS calls I don't think we should release.
Yes, I agree.
But it seems to me that we are making quite some progress
and hopefully have mostly done very soon.
Also as I noted before I think we should introduce a minimal
navigation framework using UUID to make sure that one can
easily move stuff around.
+1
and defer the new repo API to 1.6.
I see the light at the horizon, but not with a fully tested JCR where
we can tell people with proper honesty, please rely your publications on
this ...
But I can stand behind it with a FS based system, where we use a
Source/RepositoryFactory
and make it very simple to switch to JCR at any time (and other
repository implementations)
at any time. This is why I am working hard to get rid of all direct FS
dependencies which
will lead to a perfect world as you probably wish.
I have more confidence in JCR
well, does it really perform and scale? Have
you really tested it under real circumstances?
No, but the Jackrabbit list suggests that others do.
than in the current file-system based
repository layer in 1.4-dev. But maybe some automated tests will
increase my confidence.
that's what we should do anyway ;-) and I will try hard
to get these tests into Lenya (also with continuous integration,
e.g. with cruise control)
That would be great. Maybe we can install cruisecontrol on our zone?
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
