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/03/30 18:26:26 UTC
Chemistry and OpenCMIS Technical Comparison
Hi,
I've posted the start of a technical comparison between Chemistry and OpenCMIS.
http://cwiki.apache.org/confluence/display/CMIS/Chemistry+and+OpenCMIS+Technical+Comparison
Obviously it will be biased, and I may have misunderstood some things
about OpenCMIS.
One thing I'd like someone from OpenCMIS to detail in this page is the
architecture of the deep hierarchy of classes around
SessionFactoryImpl / PersistentSessionImpl / CmisProviderHelper /
CmisProvider / CmisProviderImpl / CmisProviderFactory etc.
I propose that we build on this wiki page to try to figure out the
pluses and minuses of each implementation.
Regards,
Florent
PS: I'd link to the proper autoexported http://cwiki.apache.org/CMIS/
but the autoexport takes its own sweet time doing its thing.
--
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: Chemistry and OpenCMIS Technical Comparison
Posted by Florian Müller <fm...@opentext.com>.
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:fg@nuxeo.com]
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 <fm...@opentext.com> 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
Re: Chemistry and OpenCMIS Technical Comparison
Posted by Florent Guillaume <fg...@nuxeo.com>.
On Wed, Mar 31, 2010 at 4:27 PM, Florian Müller <fm...@opentext.com> 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
RE: Chemistry and OpenCMIS Technical Comparison
Posted by Florian Müller <fm...@opentext.com>.
Hi Florent,
Thanks for the answers.
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. 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.
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.
Cheers,
Florian
-----Original Message-----
From: Florent Guillaume [mailto:fg@nuxeo.com]
Sent: Mittwoch, 31. März 2010 15:40
To: chemistry-dev
Subject: Re: Chemistry and OpenCMIS Technical Comparison
Hi Florian,
On Tue, Mar 30, 2010 at 8:03 PM, Florian Müller <fm...@opentext.com> wrote:
> That's pretty accurate. I made a few changes and will add more details later.
> I've a few questions:
> - What's the repository registration for? What's the use case?
Registration in one part of the code and use in another.
For instance, registration of available repositories in some servlet
configuration code, or Nuxeo extension points, or any framework
configuration mechanism. Then user code just calls
RepositoryManager.getInstance().getRepository("default") to get the
default repo, however it's been configured. The idea is also to later
register automatically RepositoryService instances based on Java 6's
ServiceLoader.
> - Chemistry allows the definition of new property types. How is this mapped to AtomPub/Web Service?
It's not mapped for now. That's more for future extensibility than
current need, but changing from an enum to class-based constants is
always painful for user code if it's done late in the game. This can
be discussed of course.
I'll have a few questions of my own later in the afternoon :)
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: Chemistry and OpenCMIS Technical Comparison
Posted by Florent Guillaume <fg...@nuxeo.com>.
Hi Florian,
On Tue, Mar 30, 2010 at 8:03 PM, Florian Müller <fm...@opentext.com> wrote:
> That's pretty accurate. I made a few changes and will add more details later.
> I've a few questions:
> - What's the repository registration for? What's the use case?
Registration in one part of the code and use in another.
For instance, registration of available repositories in some servlet
configuration code, or Nuxeo extension points, or any framework
configuration mechanism. Then user code just calls
RepositoryManager.getInstance().getRepository("default") to get the
default repo, however it's been configured. The idea is also to later
register automatically RepositoryService instances based on Java 6's
ServiceLoader.
> - Chemistry allows the definition of new property types. How is this mapped to AtomPub/Web Service?
It's not mapped for now. That's more for future extensibility than
current need, but changing from an enum to class-based constants is
always painful for user code if it's done late in the game. This can
be discussed of course.
I'll have a few questions of my own later in the afternoon :)
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: Chemistry and OpenCMIS Technical Comparison
Posted by Florian Müller <fm...@opentext.com>.
Hi Florent,
That's pretty accurate. I made a few changes and will add more details later.
I've a few questions:
- What's the repository registration for? What's the use case?
- Chemistry allows the definition of new property types. How is this mapped to AtomPub/Web Service?
Thanks,
Florian
-----Original Message-----
From: Florent Guillaume [mailto:fg@nuxeo.com]
Sent: Dienstag, 30. März 2010 18:26
To: List-Chemistry
Subject: Chemistry and OpenCMIS Technical Comparison
Hi,
I've posted the start of a technical comparison between Chemistry and OpenCMIS.
http://cwiki.apache.org/confluence/display/CMIS/Chemistry+and+OpenCMIS+Technical+Comparison
Obviously it will be biased, and I may have misunderstood some things
about OpenCMIS.
One thing I'd like someone from OpenCMIS to detail in this page is the
architecture of the deep hierarchy of classes around
SessionFactoryImpl / PersistentSessionImpl / CmisProviderHelper /
CmisProvider / CmisProviderImpl / CmisProviderFactory etc.
I propose that we build on this wiki page to try to figure out the
pluses and minuses of each implementation.
Regards,
Florent
PS: I'd link to the proper autoexported http://cwiki.apache.org/CMIS/
but the autoexport takes its own sweet time doing its thing.
--
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