Re: [cmis] joining the TC, introduction, HTTP thoughts

["David Nuescheler" <david@day.com>]

Hi Julian,

thanks for your thoughtful post.

I am in agreement with what you are saying and would like to offer some
of my initial thoughts on a couple of your comments.

> In general, although JCR is an API, and WebDAV a wire protocol, both *do*
> define a model as well. Sooner or later, people will want to map between
> CMIS and those, so I think it's inevitable that mappings will be defined --
> this could be here, in a JSR, in an open-source project like Jackrabbit, or
> the IETF. I don't think the place matters a lot, as long as it's done
> properly.
I think this is a great exercise to go through. In my experience mapping
functionality to other specifications at a code level has definitely uncovered
issues that are hard to find.

I could volunteer our efforts at the Apache Software Foundation to be used
as an initial proposal to map CMIS to JCR. Since the implementation of
CMIS on top of JCR [1] has already begun, an initial proposal for a mapping
would be a by-product of that anyway.

I think this would also fit my function of the JCR liaison very well and
since the Apache Software Foundation is a non-profit organization
that probably all the members of the TC are contributing to already,
and the ASF has a very liberal licensing model I think this would be a great
place to get started with the CMIS to JCR mapping and possibly at a later
stage take this through a JSR (possibly JCR 2.1) and or to another
standards body.

> It's some time ago that I read the CMIS base spec, but my first impression
> was that CMIS is a proper subset of the functionality defined in JCR (maybe
> except query), and defining a mapping CMIS->JCR should be simple. The other
> way around however will be harder. It seems to me that it would be good to
> minimize differences where possible.
Agreed. I would like to stress though that I think there is
flexibility on both ends
meaning that I am more than happy to propose changes to JCR based on technical
merit.

> Furthermore, there's some overlap with current discussions on the Atom
> Protocol mailing list, such as defining extensions for hierarchical
> collections. It would be cool if we could avoid inventing this for CMIS, if
> it's already done somewhere else. In this context it would be great to have
> somebody with GData (Google Data) knowledge in the TC. Also, I expect that
> Microsoft's AtomPub experts should be involved as well (or are they here
> already?).
I would really recommend that aswell. On top of that I think that what's
called the "REST-Bindings" should probably be called the "AtomPub"
bindings and should probably be more aligned with the design patterns
used in AtomPub and other "restful" protocols.
I will file proper issues in JIRA for these things later.

Thanks again for bringing up these topics.

regards,
david