On 6/27/08, Andreas Hartmann <[EMAIL PROTECTED]> wrote: > Hi Lenya devs, > > at the meeting in Freiburg there seemed to be a general agreement about the > benefits of migrating to JCR (1.0 or 2.0) as the content repository for > Lenya, from a technical and also from a marketing point of view. For those > who didn't attend the meeting: If you're interested in the benefits we > talked about, please ask and I will try to summarize them. > > We have discussed this issue a lot of times in the past, but it hasn't been > addressed for quite some time. The situation regarding JCR implementations > has changed, and the Lenya community isn't the same as three years ago, so I > think it's worth starting the discussion again. > > A certain caution is natural - and very important - when considering a new > technology: > > 1. Insufficient knowledge to evaluate pros and cons > 2. Fear of insufficient knowledge for implementation and maintenance > 3. Danger of creating a dependency > 4. Danger of paralyzing the project because of a roadmap change > 5. Danger of dividing the community due to different fundamental opinions > 6. … (?) > > I think we have to be aware of these - and presumably other - potential > issues, and consider them thoroughly. I'm currently doing some research to > be better able to assess the more technical issues 1 to 3. You'll find my > considerations and pointers to related resources in the Wiki. Any help is > greatly appreciated. I ask some questions on the Sling list and probably on > the Jackrabbit list, please feel free to join them if you're interested. > > The issues 4 and 5 are certainly even more important, but I have the > feeling that more knowledge re. 1-3 will help us to find out whether it's > worth committing ourselves, that is, the whole community, to JCR. > > -- Andreas
I just read your (Andreas') JCR-related documents in the Wiki. Learning about JCR and possibly integration into Lenya led to one question: What is Lenya? Lenya 1.2 was: 1. XML file-based repository = transparent datastore. 2. Easy versioning of documents. 3. Easy multiple translations of documents. 4. Easy formatting of documents with XSL. 5. WYSIWYG editing of documents. 6. Functional expansion with XMAPs, XSLTs, Javascript (using JS Flow), XSPs, and Java. 7. Security 8. Search (Security and Search are listed last because they were broken/incomplete when I first encountered Lenya.) Lenya borrows #5 and #8 from other projects. (Technically, #6 derives from Cocoon, but Lenya obviously adds enough value to be a separate project.) JCR would eliminate #1 and possibly take control of #2 and #7. . Lenya 1.3 uses labels as in "Labelled Versions" from: http://wiki.apache.org/lenya/JcrContentModelAreas The other options trigger my "bad design" alert system. I can explain at length if nobody is emotionally attached to the other systems. The rest of this post assumes a revision/label approach rather than using Areas. The following explains integrating Lenya 1.3 with JCR; hopefully most applies with other versions: 1. Use JCR's versioning and labels for Translations. The only purpose of Lenya 1.3's Translation files is to define which version applies to which label. 2. Use JCR's security. Lenya 1.3 will allow different access control for the same document accessed through different Publications. I am uncertain if this can be implemented with multiple AccessManagers or requires special naming convention e.g. "mypub-username". Also (from http://wiki.apache.org/lenya/JcrAccessControl ): "Can only grant permissions, not revoke them" may require thought. What happens when the security changes in Lenya? Do we discard the current AccessManager and reassign access to all documents; hopefully not a major problem but requires thought and may be a performance issue. Lenya would handle formatting. Lenya would handle editing (mostly. WebDAV?) Lenya would business functionality. Points of uncertainty: 1. Do we have a node for each Resource and subnodes for each Translation? Or is each Translation a node and we need something else to relate the Translations to the Resource? I will assume the former for the rest of this post (since the latter requires much more thought and work.) 2. Named Resources (Content) Mostly migration and synchronization issues. Can we use JCR's UUIDs without losing functionality? The repository should be transparent to Lenya. We should be able to import/export between any two repositories without notice. Best is if we can synchronize between any two repositories. JCR's UUID is sufficient for documents created in JCR, but documents created elsewhere will need their Lenya UNID for synchronization. Using the Lenya UNID for all purposes may be easier than using the JCR UUID for special cases. How does this affect "Automatic referential integrity checks"? What are we losing by not using JCR's functionality? See http://wiki.apache.org/lenya/JcrContentModel 3. Named Resource (Design) - Design Resources require names. From the example code, this should not be an issue. Again, what do we lose by not using JCR's "Automatic referential integrity checks"? 4. WebDAV - Any editor bypassing Lenya poses a risk. Hopefully every edit creates a new version seen by Lenya. Just because someone can create a new Revision should not automatically allow the person to publish it; does JCR allow a document to be edited without granting the ability to assign labels? - Can we disable document creation without Lenya? Or force documents to align with Lenya's DTDs? Documents must follow the /Resource (with type, identifiers and access control)/Translations (with labels)/Revisions (based on the DTD of the Resource type). Will other editors corrupt Lenya? Proper research would answer most of my questions. Lenya 1.3 will gain JCR support. JCR integration should require about one week of work after Lenya 1.3 is completed. I am unlikely to have implement this until sometime next year. Back to the main question: What is Lenya? If JCR handles many functions of a CMS, what value does Lenya add? If Lenya only supports JCR, how is Lenya different than other JCR-based CMSes? (My last post explains why I feel keeping the file-based repository is important, but the parent post implies this is an either/or decision rather than additional functionality.) Hoping this post was not irrelevant or confusing, solprovider
