You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by Florent Guillaume <fg...@nuxeo.com> on 2010/04/09 20:46:02 UTC
Merge proposal
Hi all,
I've played quite a bit with OpenCMIS to get a good idea of how it
works and it is implemented.
For the merge I propose to take the OpenCMIS code base as a starting
point, and refactor some things in it by using the experience gained
in the Chemistry code base. Here are the tasks I propose we start
with. Most of them are independent but the first two are the most
important IMHO.
Everything is here to be discussed of course.
We can also discuss the name of the final code base (Chemistry or
OpenCMIS or something new) but please in a separate thread or face to
face :)
1. Merge the Client Provider SPI and the Server SPI into one.
This is already the architecture in Chemistry, and it's proven to be
very useful:
- It makes it possible to run the same unit tests on the client or on
a server implementation.
- It diminishes notably the number of classes.
- It allows plugging directly into a backend at the Java level without
delegation or overhead.
Concretely, this would mean merging the following classes and their
related dependents:
org.apache.opencmis.client.provider.spi.CmisSpiFactory vs
org.apache.opencmis.server.spi.AbstractServicesFactory
org.apache.opencmis.commons.provider.*Service vs
org.apache.opencmis.server.spi.Cmis*Service
The points that Florian raised about having not exactly the same
methods, or passing a call context or an objectInfos, are all valid
but can be solved simply IMHO.
2. Merge data transfert object interfaces
For instance
org.apache.opencmis.commons.provider.AllowableActionsData vs
org.apache.opencmis.client.api.AllowableActions
org.apache.opencmis.commons.provider.ContentStreamData vs
org.apache.opencmis.client.api.ContentStream
org.apache.opencmis.commons.provider.RepositoryCapabilitiesData vs
org.apache.opencmis.client.api.repository.RepositoryCapabilities
etc.
This would make a class like
org.apache.opencmis.client.api.repository.ObjectFactory dedicated to
turning objects from one API into another similar one mostly obsolete.
Copying objects into new objects is bad in general. Cloning objects
would still be useful but that's all.
Only the org.apache.opencmis.commons.impl.Converter that deals with
converting to- and from- this model to JAXB would have to be kept.
3. Merge the 9 service interfaces into one
(Except maybe for RepositoryService). This helps users dealing with
the SPI see single interfaces which is good because Java developers
often don't think in terms of services, they just want an object
(equivalent to a connection) on which they can call methods. This also
simplifies implementations somewhat (one less delegation to a common
"store manager").
4. Simplify passing of inclusion parameters
The provider methods often take includeAllowableActions,
includeRelationships, renditionFilter, includePolicyIds, includeAcl,
etc. Chemistry uses a single "Inclusion" record here, which makes the
APIs more readable without losing generality.
5. Make data interfaces more Javaish
For instance ObjectData.getProperties().getProperties() is not
natural. Although it's close to the JAXB model, it's not necessary to
have it in our interfaces, and the Converter class can deal with this
easily.
There is a lot of Boolean passing where a simple boolean would be sufficient.
The whole ObjectData / ObjectList / ObjectInFolderList /
ObjectInFolderData / ObjectInFolderContainer / ObjectParentData coming
from JAXB should probably be rethought in a more Javaish way.
6. Simplify some client APIs
For instance Folder.createDocument(properties, contentStream,
versioningState, policies, addAces, removeAces, context) is too
complex for a client API.
7. Extract a generic TypeManager into commons
There's a simple one in the InMemory provider that would benefit other
backends. Or the one from Chemistry can be used.
8. Import the Chemistry ANTLR3 CMISQL parser
The inmemory implementation would have to be adapted (and completed) of course.
9. Other details
Rename *ObjectType* into *Type* (we only have on kind of "type", the
one of objects)
Rename BaseObjectTypeIds into BaseTypeId, as it's customary to name
enums in the singular.
Florent
--
Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
RE: Merge proposal
Posted by Florian Müller <fm...@opentext.com>.
Thanks, Florent, for your proposal. It's a great starting point. Here is a quick response. We should talk about the details next week.
Re 1.
I'm afraid that's possible in all cases. For example, you need more data to generate a complete CMIS Atom entry than you get out of a
getObject() call. Client and (AtomPub) server are not symmetrical. That's not an implementation issue but a spec issue. But maybe I'm missing something.
Re 2.
That's more a philosophical question. At the moment there is quite a strict separation between the provider API and the client API.
Personally I'm fine with blurring this line and reusing the DTOs. I agree that copying objects is not really necessary.
Re 3.
Are you talking about the provider API or the server SPI here? On the server side I'm with you. The provider API was strictly modeled after the spec. It makes it easier to understand and use. We should discuss that next week.
Re 4.
This is similar to 3. The question is how close should the provider API be to the spec. The client API already has an equivalent to Chemistrys "Inclusion".
Re 5.
There is a simple reason why it is as it is: extensions. All these objects follow the CMIS schema and the schema allows extensions basically everywhere. If we would give up support for really every possible extension point then the interface could be nicer. But that's a big decision. Are we ok with not supporting everything? If so, how do we decide what to support and what not?
Regarding Boolean and boolean. They are intentionally not simple booleans. If a server does not return a value (= doesn't include that
tag) we have no clue if it defaults to true or to false and we need a third state which is null (= we don't know). Yes, such a repository would not be completely spec conformant. But I'm sure we will see half complaint repositories sooner or later.
Re 6.
Agreed.
Maybe the persistent and transient interfaces should be different. That's a topic we should discuss.
Re 7.
Makes sense.
Re 8.
That would be great!
Re 9.
I support everything that makes the interfaces more usable, readable and conformant. These renamings make sense to me.
Looking forward to the meeting,
Florian
-----Original Message-----
From: Florent Guillaume [mailto:fg@nuxeo.com]
Sent: Freitag, 9. April 2010 20:46
To: List-Chemistry
Subject: Merge proposal
Hi all,
I've played quite a bit with OpenCMIS to get a good idea of how it
works and it is implemented.
For the merge I propose to take the OpenCMIS code base as a starting
point, and refactor some things in it by using the experience gained
in the Chemistry code base. Here are the tasks I propose we start
with. Most of them are independent but the first two are the most
important IMHO.
Everything is here to be discussed of course.
We can also discuss the name of the final code base (Chemistry or
OpenCMIS or something new) but please in a separate thread or face to
face :)
1. Merge the Client Provider SPI and the Server SPI into one.
This is already the architecture in Chemistry, and it's proven to be
very useful:
- It makes it possible to run the same unit tests on the client or on
a server implementation.
- It diminishes notably the number of classes.
- It allows plugging directly into a backend at the Java level without
delegation or overhead.
Concretely, this would mean merging the following classes and their
related dependents:
org.apache.opencmis.client.provider.spi.CmisSpiFactory vs
org.apache.opencmis.server.spi.AbstractServicesFactory
org.apache.opencmis.commons.provider.*Service vs
org.apache.opencmis.server.spi.Cmis*Service
The points that Florian raised about having not exactly the same
methods, or passing a call context or an objectInfos, are all valid
but can be solved simply IMHO.
2. Merge data transfert object interfaces
For instance
org.apache.opencmis.commons.provider.AllowableActionsData vs
org.apache.opencmis.client.api.AllowableActions
org.apache.opencmis.commons.provider.ContentStreamData vs
org.apache.opencmis.client.api.ContentStream
org.apache.opencmis.commons.provider.RepositoryCapabilitiesData vs
org.apache.opencmis.client.api.repository.RepositoryCapabilities
etc.
This would make a class like
org.apache.opencmis.client.api.repository.ObjectFactory dedicated to
turning objects from one API into another similar one mostly obsolete.
Copying objects into new objects is bad in general. Cloning objects
would still be useful but that's all.
Only the org.apache.opencmis.commons.impl.Converter that deals with
converting to- and from- this model to JAXB would have to be kept.
3. Merge the 9 service interfaces into one
(Except maybe for RepositoryService). This helps users dealing with
the SPI see single interfaces which is good because Java developers
often don't think in terms of services, they just want an object
(equivalent to a connection) on which they can call methods. This also
simplifies implementations somewhat (one less delegation to a common
"store manager").
4. Simplify passing of inclusion parameters
The provider methods often take includeAllowableActions,
includeRelationships, renditionFilter, includePolicyIds, includeAcl,
etc. Chemistry uses a single "Inclusion" record here, which makes the
APIs more readable without losing generality.
5. Make data interfaces more Javaish
For instance ObjectData.getProperties().getProperties() is not
natural. Although it's close to the JAXB model, it's not necessary to
have it in our interfaces, and the Converter class can deal with this
easily.
There is a lot of Boolean passing where a simple boolean would be sufficient.
The whole ObjectData / ObjectList / ObjectInFolderList /
ObjectInFolderData / ObjectInFolderContainer / ObjectParentData coming
from JAXB should probably be rethought in a more Javaish way.
6. Simplify some client APIs
For instance Folder.createDocument(properties, contentStream,
versioningState, policies, addAces, removeAces, context) is too
complex for a client API.
7. Extract a generic TypeManager into commons
There's a simple one in the InMemory provider that would benefit other
backends. Or the one from Chemistry can be used.
8. Import the Chemistry ANTLR3 CMISQL parser
The inmemory implementation would have to be adapted (and completed) of course.
9. Other details
Rename *ObjectType* into *Type* (we only have on kind of "type", the
one of objects)
Rename BaseObjectTypeIds into BaseTypeId, as it's customary to name
enums in the singular.
Florent
--
Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87