I think the CMS should support the following seperation:
[frontend] - [CMS(1)] <- promotion <- [CMS(2)] - [backend]
| |
[store] [store]
In this picture CMS(1) is optimized for publishing/speed and CMS(2) is
optimized for workflow, version mgmt and versioning.
Does this make sense for your KMS?
Michael.
-----Original Message-----
From: Stefano Mazzocchi [mailto:stefano@apache.org]
Sent: dinsdag 22 januari 2002 14:53
To: Apache Cocoon
Subject: Promotions, Revisioning and Workflow
Ok, now that I know what Robert meant with 'promotions' I want to give
you my impressions.
1) I've been talking about this 'CVS for XML' on the Xindice-dev mail
list. Check the mail archives
http://marc.theaimsgroup.com/?l=xindice-dev&r=1&w=2
2) I believe that a KMS *must* have the ability to do version control
and workflow management. Integrated. The two together, give you
'promotions'.
3) CVS is not enough.
4) Subversion is *much* better (http://subversion.tigris.org) but still
is 'file' based, an XML-based KMS needs 'node-granular' versioning
metadata
My dream KMS architecture is something like this:
[frontend] - [CMS] - [backend]
|
[store]
where cocoon powers both 'frontend' and 'backend', CMS wraps around an
native XML database and provides versioning, access control, transparent
query filtering and all the required things. 'store' is implemented with
a mix of 'native XML databases' and 'relational databases' (depending on
the needs, still I haven't designed the whole concept, but I'm not sure
that a native XML DB is capable of doing everything without serious
performance degradation).
What do you think?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<stefano@apache.org> Friedrich Nietzsche
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
|