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
