Intro
This page investigates options we have for providing a Content Repository as quickly as possible?
There are some constraints to work within:
- Alfresco is the core Repository/CMF
- Future enhancement is not prohibited
- Enough capability is provided to support an inital Alfresco offering
Features to Provide
Repository Interfaces
Standard Repository Interfaces now exist:
- WebDAV
- JSR-170
- FTP
- Net Drive
They're good for:
- quick community adoption
- gradual improvement / re-factor of implementation
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!!
- WebDAV (many clients are aware)
- Proprietary I/F (for our own portlets, clients to stop migration to another repo in the short-term??)
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.
Repository Differentiators
We also need to differentiate our Repository from others. We can do that by providing:
- Content Behaviour - Lifecycle, Workflow, Business Logic
- Integrated Collaboration
- Content Configuration (longer term) - Branch/Merge/Tag/Diff
- Distributed capabilities (longer term) - Multiple site authoring, Inter-site links, Aggregated Publishing
- Enterprise Administration (longer term) - Backup/Restore, Console
- Content Service Development Kit (longer term)
But not all in one go; the minimum for a first release that supports Portal based solutions is: Please Comment!!
- Some form of Content Behaviour for at least Publish lifecycle
- Some form of Collaboration for at least Team working
Methods for Repository Provision
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!!
Existing Open Source Repository Projects
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 |
Alfresco Repository V1: Slide Based
Use Existing
- Take Slide as is (provision of WebDAV)
- Wrap Slide in an Alfresco proprietary interface for short term CMF features (note: this could be difficult)
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 ===
- Take Slide Front-end (for security etc) and build minimal plug-in store based on WebGAV
- Wrap WebGAV in an Alfresco proprietary interface for short term CMF
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.
Alfresco Repository V1: JackRabbit Based
Contribute
- Take JackRabbit as is (provision of JSR-170)
- Fix it and plug holes to get reliable, complete implementation (contributing back to Apache)
- Add a WebDAV facade
- Implement a proprietary interface for short term CMF
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.
Alfresco Repository V1: Alfresco through and through
Aggregate
- Take WebGAV (existing investment)
- Integrate Lucene (already done)
- Integrate Spring+Acegi – for security & architecture direction
- Convert CRAPI to public proprietary I/F
- Extend CRAPI to include short term CMF
- Choose when to include
- Type System
- Integration with Hibernate
- Integration with Subversion
- Could consider using Slide for Front-end (security) **
- Add JSR-170 as facade, perhaps using JackRabbit where possible
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.
Chosen Approach
To be decided. Insert non-formatted text here
