This page investigates options we have for providing a Content Repository as quickly as possible?
There are some constraints to work within:
Standard Repository Interfaces now exist:
They're good for:
But, with these, the Content Repository is becoming a commodity.
Ok, which interfaces must we expose in the first release of the Repository? Please comment!!
JSR-170 is something we are seriously considering - the specification is not v1.0 yet, and there are few clients that actually talk JSR-170 except Magnolia! We can always add this as a façade in the future.
We also need to differentiate our Repository from others. We can do that by providing:
But not all in one go; the minimum for a first release that supports Portal based solutions is: Please Comment!!
The following table depicts the advantages and disadvantages of four different methods of provisioning a Content Repository and CMF. The scores in brackets range from 1 (least attractive) to 3 (most attractive).
Community | Ownership | Time to Market | Re-Factor | Addition of CMF | Total | |
---|---|---|---|---|---|---|
Use existing repo & contribute | Grab immediate community share (3) | None (1) | Immediate (3) | N/A (3) | Hard (1) | 11 |
Build from scratch | Organic growth (1) | Full (3) | Slow (1) | N/A (3) | Easy (3) | 11 |
Fork existing repo | Unknown (1) | Full (3) | Medium (2) | High (1) | Medium (2) | 9 |
Aggregate existing tools | Pool communities of building blocks (2) | Full (2) | Medium (2) | N/A (3) | Easy (3) | 12 |
Simple totalling of the scores indicates that we should go and aggregate existing tools and fill out the rest ourselves. Of course, there's no weighting on the factors and some factors may even be missing. Please adjust, if you feel the need!!
The following table compares some of the currently available Content Repository open source projects.
Feature | Interfaces | Back-end | Security | Version | Query | Reliability | Community | Meta-data | Other |
---|---|---|---|---|---|---|---|---|---|
Slide | WebDAV | Pluggable Stores | ACL | Checkout/in | DASL | Questionable | Apache, Java, V2 | Properties | Events |
JackRabbit | JSR-170 | Database, InMemory, Object, XML | ACL (JAAS) | Linear Checkout/in eventually | JCRQL/Lucene | Transactions (Depends on datastore) Path search? | Apache, Java, Incubator | Type System | Events |
Subversion | WebDAV | File or Berkeley DB | Authenticate Only | Full (branch, merge, tag, diff) | None | Used by Dev. Teams | Collab.NET, C, V2 | Properties |
Provides very quick route to Repository - but to implement the longer term CMF features, Slide would need to be replaced and ownership is Apache. Good as a stepping a stone.
Est. Time to Deliver: TBD.
=== Fork or Contribute ===
Provides ability to hook into Slide community whilst providing a differentiator at the back-end at relatively low cost - but again, Slide front-end slowly gets re-factored / eaten away by longer term CMF implementation.
Update: Having looked at the Slide plug-in architecture, I don't think this is a good approach. First, the store contract is all about storing and retrieving values - so it's good at isolating file vs db stores, but it doesn't really allow a different implementation behind the scenes. Second, apart from providing a WebDAV protocol and security, I'm not sure that Slide provides much else outside of the store. Third, the Slide 3.0 talk is all about re-structuring the Slide architecture including how to incorporate different back-ends.
Provides ability to hook into JackRabbit/170 community whilst getting a Repository at relatively low cost.
Est. Time to Deliver: TBD.
But at some point, we would need to fork JackRabbit to support the longer term CMF features. Our implementation of JackRabbit will require some major re-factoring to support DB, Versioning, Distribution, Security for example.
Provides us with a Repository that is owned by Alfresco, but at a cost that is more expensive than just taking Slide or JackRabbit out-of-the-box. We can pool several communities and state our architecture intention from the start. Re-factoring is less of an issue.
Est. Time to Deliver: TBD.
** Update: Having investigated Slide, this is probably not going to save us much ramp-time.
To be decided. Insert non-formatted text here