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
