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:f...@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