The content repository has a large API. This makes it hard to learn, which slows development. But most of this can be solved trivially by extracting the services it provides e.g. keywords, and making them applicable to all acs objects. The remaining two features of the CR are the facilty to store blobs of stuff, and versioning.
The first of these seems like a historical accident. DB usage behind websites evolved into CMS's when people thought it a good idea to store their blobs of indivisible stuff (magazine articles generaly) in the db. But these days the line is pretty blurry between what is a piece of content and can be squeezed into blob-of-stuff-plus-title and what deserves it's own table with structured attributes.
The second feature of the CR, versioning, is the most interesting because it is not tackled any where else in the toolkit. I see versioning play two roles:
- Revisions: An object is revised, for example a magazine article going through an approval process or a bboard posting being edited by a moderator, where the newest revision becomes the canonical version of the object and the previous revisions serve as an audit trail.
- Alternatives: An object has more than one representation, for example the English and French versions of the description of a product in a catalogue, where each description is equaly valid but appropriate in different contexts.
Versioning applies to more than just indivisible blobs of stuff, so there needs to be a mechanism for all acs objects to store and represent revisions and alternatives. The CR is not bloated with useless features, those features need to be moved and expanded. What's left of the CR is a convenient API for storing stuff in the filesystem with metadata in the db.
