Hi Florent, There are three reasons why these interfaces are different.
1. AtomPub and Web Services differ in some operations on the server side. The Navigation Service is actually a bad example because AtomPub and Web Services are equal here. But have a look at the other services. The JavaDoc states which binding will call which method. The create calls, some versioning calls and the ACL calls have to be different. So, the server SPI has to be a bit more verbose, which unfortunate but inevitable. We could have used these verbose interfaces as the provider API but that would have been confusing for application developers. 2. All methods of the server SPI have an additional parameter "context". It transports data related to the call to the server implementation. Username, passwords and which binding is used are the most prominent pieces of data. But it could be also anything else an authentication provider wants to pass through. With this parameter the server implementation can be stateless and threading issues can be minimized. I think the context parameter is comparable with the Map that is passed to Repository.getSPI() in Chemistry. I assume you have to create a Chemistry SPI object for every call. That is not necessary in OpenCMIS. This parameter doesn't make much sense for a provider API. 3. Many methods of the server SPI have another additional parameter "objectInfos". This is only required for the AtomPub binding. It passes additional data about the involved objects back to the framework. This is necessary to generate all the links accordingly to the spec. This parameter also doesn't make sense for a provider API. Btw. If I read the Chemistry code correctly, the link handling in Chemistry isn't perfectly complaint with the CMIS spec, yet. Some links are missing and some links are exposed that shouldn't be (always) there. There are also some issues with the required Atom tags - as far as I can see. In OpenCMIS the parameter "objectInfos" is used to overcome exactly those kinds of issues. - Florian -----Original Message----- From: Florent Guillaume [mailto:[email protected]] Sent: Mittwoch, 31. März 2010 20:41 To: chemistry-dev Subject: Re: Chemistry and OpenCMIS Technical Comparison On Wed, Mar 31, 2010 at 4:27 PM, Florian Müller <[email protected]> wrote: > I get the repository registration idea but I don't see it that prominent in > the API. There are too many frameworks out there that a one-fits-all approach > works everywhere. True, and nothing prevents one from just instantiating an APPRepositoryService() directly if needed. > Additionally, the fact that the RepositoryManager is a singleton might become > a problem in some environments. I think the native service provisioning > mechanisms of the frameworks are a better choice. There's always a singleton somewhere, be it JNDI, the ServiceLoader, the Servlet Application Context, or something else. It's juste that until we'd decided what was most generic I decided to use a simple class to multiplex the various repository service providers. > Defining new property types is problematic. If you do that and serialize them > similar to the standard CMIS properties, most CMIS clients won't recognize > them. Either you create a none schema complaint XML or you generate a tag > that is ignored by most clients. Additionally, you cannot express that in the > object type definition. The property type is an enum there. > A solution for a non-standard property type could look like this: A property > of this new type is exposed as a String property. The value is a string > representation of the property value. All CMIS clients should be able to, at > least, read and display it. The real value of the property is wrapped into a > extension of that property (a tag within the property tag). A client that can > handle the non-standard property type would ignore the string value and use > the value in the extension tag instead. Yes that's a good way to do it. I'm not saying that I want to keep property types as a non-enum, just that the extension problem has to be though about. Now questions of my own about OpenCMIS: - Why is there a difference between the CmisSpi level and the AbstractServicesFactory level? Or, going to specific services, why is there a difference between org.apache.opencmis.commons.provider.NavigationService and org.apache.opencmis.server.spi.CmisNavigationService ? These are the two API levels that are merged in Chemistry, and I don't see what you get by separating them in OpenCMIS. It just makes for complex forwarding of calls, see for instance org.apache.opencmis.inmemory.clientprovider.NavigationServiceImpl. 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
