|
Sunday 14 September 2008 3:16:08 pm
It could be very interesting indeed, if it becomes widely adopted and is not used as a fud tool used by "big name" vendors as a pure marketing ploy... After a short reading of the spec, here's my thoughts about implementing it in eZ: cmis is based on a content model made of folders (organized in trees), document objects (made of arbitrary attributes), relationships and acls. Methods are defined to create,delete,modify and move content.
- a folder cannot be multipositioned
- content has to be accessed using only one language for each repository - no multilang manipulation allowed
- objects can only have 1 binary stream associated (ie. binary file attribute)
- folders cannot have binary streams associated
- permissions to create a specific object in a specific folder do not depend on current user
- the concept of "unfiling" means taking an object out of the content tree. It could be unsupported (and still be spec compliant) or mapped to the trashcan
- object attributes are based on a very limited set of datatypes; eZ has them all except for "html text"
- objects relations can be of many types. apart from that, they looks like eZ object relations
- the concept of "checkout" and "working copy" is introduced
- the SOAP binding, which is mandatory as well as the REST one, needs a lot of WS-* junk. The current eZ SOAP code is quite lacking.
The cmis model looks thus mostly like a subset of the eZ model. This means that spec integration could be done in 3 steps, ordered by technical difficulty:
- allow importing of data from a cmis repository
- allow exporting a "view" of ez data to a cmis repository / manipulation of data by a cmis client
- allow live, transparent manipulation of a cmis repository data as part of ez content
Principal Consultant International Business
Member of the Community Project Board
|