-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have a strong +1 for the plan to do this in the sandbox and otherwise driving Rave's extensibility.
Marlon On 3/15/12 5:02 AM, Ate Douma wrote: > Hi Ravers, > > I'd like to introduce a proposal for adding content services to Rave. > > The plan is to extend and enhance Rave with a content services layer to > dynamically manage and retrieve content, markup, etc, as well as custom > domain models through a hierarchical content repository based on JCR (Java > Content Repository) [1] and Apache Jackrabbit [2]. > > Such JCR based content services will allow storing and managing Rave web > front-end elements like pages, templates, layouts, headers, images, styling > and component view rendering fragments dynamically in a central back-end, as > well as other (custom) domain objects to be used by Rave itself or through > widgets. > > Note: the term 'content' in 'Java Content Repository' is quite loosely > defined: anything can be regarded as 'content' and a JCR typically stores > much more than 'web' content as such. The Airavata podding uses it for > storing and maintaining workflow and services definitions in the Airavata > Registry, and Wookie has an optional back-end storage on JCR as well. Which > might come in handy for Rave too ;) > > Our initial plan was to prepare a code donation from our Hippo Site Toolkit > product (HST) [3] which already provides these features through a very > light-weight multi-site development and management framework. Furthermore HST > provides a context mapping engine which will be very useful and IMO also > needed for Rave (but later). > > However, after thorough review and some prototyping work, we've come to the > conclusion that providing this through a code donation will require too much > upfront work (on our side) to refactor out critical but only Hippo specific > functionalities. > > So, we've decided to go about the other way around: to start from scratch > within Rave itself. This also allows and invites the Rave community to > participate from the start, for a more agile process and better alignment of > architecture and functionality. But we can still use Hippo HST, which is > open-source and available under ASL 2.0 license, as example and reference for > this purpose. > > Initial participation and contributions for this work will be provided by > myself, Ard, Unico and Marijan (all Hippo employees), and we have explicit > time and budget allocated to work on this over the coming months. And of > course we hope others from the community are willing to chime in and > participate as well. > > This proposal has also preliminary been reviewed and discussed with Matt > Franklin and Bill Donaldson of MITRE. They support the proposal and are > willing to commit resources to the proposal if agreed to by the community. > > I intend this email only as introduction: I will provide more detailed > information on the goals, tasks and possible future work in separate emails. > Below I just briefly describe an overview of the groundwork tasks, features > and concrete modules we intent to start working on. > > And, as this proposal will/should impact and enhance the Rave architecture, > we propose to start initially in a Rave sandbox, building on top of Rave, not > fork it. This will thereby also help pull and push the Rave modularization, > extendability and configuration discussions. > Future merging back into the main Rave project, or as optional extension > modules is of course the intend but something to be decided when the time is > right. > > The features and tasks we intend to work on for the groundwork are: > > * A separate rave-jcr war module exposing and bundling a Apache Jackrabbit > content repository through a service layer. > > * A rave-jcr-config module (or modules) providing low-level JCR > administrative features like for import/export, and content type and content > bootstrap and upgrade functionality. > > * A rave-jcr-ocm module for Object Content Mapping (OCM) support. Jackrabbit > already provides a jackrabbit-ocm module for this [4], but it can use some > improvements and enhancements, as well as generic Rave integration support. > Furthermore, the latest released jackrabbit-ocm is a bit outdated and still > on JCR 1.0 level, while a newer but unreleased JCR 2.0 based version is > available in their sandbox. So we intend collaboration on this with the > Jackrabbit developers (note: Ard is also Jackrabbit committer). > > * Introducing a HMVC pattern based solution for rave-web-*. > This feature/enhancement definitely requires separate discussion, beyond and > independent of this proposal for which I'll open a separate thread. > It boils down to replacing or enhancing the current single (simple) Spring > MVC interaction for the portal to a Hierarchical MVC (HMVC) based solution. > This will be needed to support a more generic and extensible front-end > layout, aggregation and rendering architecture. > For quick info, see [5], and I'll come back on this shortly with more details. > > * A rave-web-jcr module which will provide concrete OCM and JCR service > usages to manage, map and access Rave web features like pages, regions, > menus, layouts and (view) templates stored in the JCR. This module also will > support and make use of a HMVC pattern as described above. > > * A rave-jcr-console war module. To help working with a JCR engine, both for > development as well as for low-level runtime administration, we'll provide an > optional rave-jcr-console war module, which can be used to browse and modify > a JCR store at runtime on node/property level as well as provide (pluggable) > front-end tooling for import/export node type and namespace management, etc. > For this purpose Hippo provides an open-source ASL 2.0 licensed > JCR/Jackrabbit web console [6], without any Hippo specific dependencies. > Note: this is not a code donation but can be easily leveraged as optional > tooling for Rave. > > Beyond this, at a later stage we also intend to provide or start work on a > "context mapping engine" (CME) for Rave, but first we like to get the above > groundwork features in place. > > Assuming lazy consensus on the overall goals (not the details), I intend to > start with creating a content-services sandbox project early next week. > And Ard, Unico and Marijan are expected to engage in the effort starting from > April 1st. > > Any feedback on this initial proposal and further engagement on discussing > these features and their implementation are of course very much appreciated! > > Regards, Ate > > [1] http://www.jcp.org/en/jsr/summary?id=283 > [2] http://jackrabbit.apache.org/ > [3] https://wiki.onehippo.com/display/CMS7/7.7+Hippo+Site+Toolkit+Wiki+pages > [4] http://jackrabbit.apache.org/object-content-mapping.html > [5] > http://techportal.ibuildings.com/2010/02/22/scaling-web-applications-with-hmvc/ > [6] http://svn.onehippo.org/repos/hippo/hippo-jcr/console/trunk -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPYf2GAAoJEEfVXEODPFIDedMH/jQo1Srf5fT9AXew2WxXgBlO emQMctQK3UjbbLybyLnP5bqnikkrq3j42wJe8CliHDuZDooQ7TapMmC8OW2q7/A2 gOYUx0stKmjeDka1wkHVO+SUG2509Ph6K83ca0BXqDGJKd2u0xUTDzkcWFUfcdh9 kTFbIL2Rqz5x1IqKgPmbNS8jCX7vFtHou6NNUOsqGlDcRFhcPGWMT8T44pKuey8/ pyfFoonGz1THcKwhfESaa0bX8sbTEKlw6r7IXYEk3Ex/p/nHEdgcpMLk04DDRjWb Ywtx5SrptJubZ4+yQeu99l6LUktQ3eIzUSPLNLzKjB9NE1kHANvTKHH6K1Aa/gs= =LAXJ -----END PGP SIGNATURE-----
