J. Wolfgang Kaltz wrote:
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",
Actually the main purpose of this was to create an abstraction for
content handling and therefore a single point to apply repository
related changes. This should lower the barrier of JCR integration.
Like I already said, IMO approach 1 is the way to go.
[...]
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 ?
I'd start with the single node approach (which wouldn't require any
changes, because the sitetree is just stored in a lenya:// source).
In a next step, the TreeSiteManager could store the tree nodes
in single sources, which would allow to use meta data for node properties
and probably improve performance by using repository queries instead of DOM
traversal.
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
+1
-> but maybe also other things, such as XSLs, CSSs, ... we probably
should start with sitetree+content first and worry about these later
Yes
3. we need to decide how to configure the decision: what is retrieved
from file, what from JCR, what from etc.:
That would require another layer which maps URIs to repositories.
In a first step I wouldn't allow this configuration - all lenya://
requests go into the Lenya repo which is either based on sources
or JCR (depending on the NodeFactory).
-> 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;
Yes
2. implement a configuration mechanism for the decision "which content
item / which source" (see above)
IMO that should be defered, but we can already discuss it
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
Same as 2.
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
Actually it's context:// sources from the Lenya point of view.
will still work.
I agree.
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 !
At least as a first step. I already mentioned in a previous mail that
we will leave the source (file) repo implementation behind as soon as
we want to leverage JCR features that can't be easily implemented
using sources. But even then the additional layer won't hurt, even
if JCR is the only implementation.
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.
I agree.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
