incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <>
Subject Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Date Fri, 11 Dec 2009 19:41:43 GMT

On Fri, Dec 11, 2009 at 7:10 PM, Florian Müller <> wrote:
> But you are actually comparing two different levels of APIs. The
> opencmis-provider-api handles simple immutable data objects while
> chemistry-api follows an object-oriented approach. As far as I know
> Chemistry has nothing comparable to the opencmis-provider-api.

I wouldn't say so. For example, here's how you get selected properties
of an object in a given repository (assuming I've understood the APIs


    CmisProvider provider = ...;
    ObjectService service = provider.getObjectService();
    PropertiesData data = service.getProperties(
        "repositoryId", "objectId", "filter", ...);
    Map<String, PropertyData<?>> properties = data.getProperties();


    RepositoryService service = ...;
    SPI spi = service.getRepository("repositoryId").getSPI();
    ObjectEntry entry = spi.getProperties(
        spi.newObjectId("objectId"), new Inclusion("filter", ...));
    Map<String, Serializable> properties = entry.getValues();

I'd don't think the APIs are too different. At least they certainly
are comparable.

Would it at least make sense for the projects to share a common
org.apache.cmis package with with things like constants defined in the
CMIS standard and other basic concepts that everyone can agree with?

> We derived our design from a lot of prototypes and applications that we
> have built over the past 20 months. Some code fragments and concepts
> are actually pretty old now. We had a lot of it in one shape or another when
> Chemistry started. That's why Chemistry was never an option for us.
> The code bases of Chemistry and OpenCMIS have been developed at the
> same time taking different routes. Chemistry did that in the public, most
> of OpenCMIS was created behind closed doors.

This paragraph should definitely go into the OpenCMIS proposal. It
gives a much clearer rationale for the separate project than the API
and scope differences mentioned in the original proposal.

I definitely understand the value of the existing code base. It's a
bit unfortunate that we now have two codebases for pretty much the
same thing, but I guess we just have to live with that for now. In
fact some healthy competition may even be good for both projects. In
the interest of avoiding further fragmentation I'd like for us to find
ways for the two projects to coexists and cooperate. To do that, I'd
be happy to help mentor OpenCMIS either as a part of Chemistry or as a
separate podling.


Jukka Zitting

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message