Michael Wechner schrieb:
(...)
JCR integration makes it more stable, because the Content Repository API
will
be unified.
It seems to me we are currently discussing 2 completely separate
approaches regarding JCR integration, so maybe that's why there are some
misunderstandings ?
Approach 1, top-down,
that is, change Lenya core to abstract it from using directories and
files, so that other "backends" can be used (JCR, Database, etc.). This
is the work we have been doing so far in 1.4, but it's true that it's
not finished. Andreas has introduced a "lightweight repository", whose
documentation was started (but not yet completed) in
http://wiki.apache.org/lenya/OverviewRepository. The basic idea is that
content access goes via the "lenya://" protocol; the implementation of
that protocol can then decide where to get the stuff from. I changed
document creation code to use this protocol instead of java.io.File, and
disentangled the metadata handling from the files to also use this
protocol. Unfortunately I currently don't have time to see what the
status of reading content and of constructing the site tree is,
regarding this "lenya://" protocol.
Approach 2, bottom-up,
that is, take Jackrabbit and change Lenya to use this layer instead of
what it is doing now. AFAIK this is what Michi is proposing ?
* I don't think all devs realize that 1.4 already handles content access
quite differently from 1.2. ! *
So I am indeed wondering how the bottom-up approach would actually be
implemented.
AFAICT the design issues that must be resolved for JCR integration in
Lenya are
1. how is the sitetree handled ? Stored and retrieved as a single node
in JCR, or constructed dynamically by reading all content nodes ?
2. we need to decide which types of "lenya://..." requests are
potentially to be handled by a JCR, and which are not:
-> clearly this concerns all content items: so probably, any request
"lenya://lenya/pubs/*/content/*" may be delegated to JCR
-> but maybe also other things, such as XSLs, CSSs, ... we probably
should start with sitetree+content first and worry about these later
3. we need to decide how to configure the decision: what is retrieved
from file, what from JCR, what from etc.:
-> at publication level ? (i.e. the entire publication content either
comes from file, OR from JCR, OR from ...)
-> at content item level ? (i.e. each document/asset knows - maybe
via its metadata where it comes from)
For implementation IMO the next steps are
1. make sure all content access goes via "lenya://" and no longer uses
java.io.File directly;
2. implement a configuration mechanism for the decision "which content
item / which source" (see above)
3. change the implementation of the "lenya://" protocol to decide that
certains requests no longer access a java.io.File but instead a JCR
repository
Regarding the stability of Lenya, quite frankly, I think the bottom-up
approach is more dangerous. The top-down approach consists of
abstracting Lenya content access, but obviously current implementation
via java.io.File will still work.
IMO if we follow the top-down approach, we will have painless,
configurable JCR integration, and I see no reason it should not be a
part of the 1.4.X series. In my view JCR integration will not be a
fundamental redesign, but a configuration option at the Lenya repository
abstraction level. And this level already exists in the current 1.4 source !
Bottom line, JCR CAN be available as part of Lenya 1.4.X (but probably
not 1.4.0), and WILL be available as soon as someone implements it,
because she needs it and/or wants it.
--
Wolfgang
begin:vcard
fn:J. Wolfgang Kaltz
n:Kaltz;J. Wolfgang
email;internet:[EMAIL PROTECTED]
tel;work:+49 203 379 2276
tel;fax:+49 203 379 3557
x-mozilla-html:FALSE
version:2.1
end:vcard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
