OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cmis message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Thank you for your comments. I think you bring a lot of value and experience to the TC. When we looked at creating the REST binding, we had really three options: base on AtomPub, base on WebDAV, or start something new. We chose to base the binding on AtomPub since it was getting good traction and seemed to fit the needs well. AtomPub was also easy for developers to understand. So it was quite interesting from all perspectives. This does not mean we cannot have a WebDAV-based binding in the future provided the charter allows.

I am not so concerned with JCR and WebDAV on top of CMIS, or CMIS on top of WebDAV or JCR. I do not think vendors will layer support that way. Generally, you do not want two+ transports when one will do as performance and latency suffers and you can write directly against that vendor's APIs whether internal or not. I am interested in the constraints WebDAV and JCR (and the other relevant standards - DMA, ODMA, etc), to the extent ECM repositories support them, impose on the repositories and thus on this effort.

I also believe that CMIS is (or can be mapped) to a subset of JCR. So it would be interesting for the JCR EG to define a profile/level that can exist directly on top of a CMIS-compliant repository. That would give Java developers alternatives to Abdera or JAX-WS APIs. I am all for that.

I have also had interesting discussions with David N about Jackrabbit exposing CMIS. As Jackrabbit is a repository, it makes sense to encourage that group to expose a CMIS interface as well. I think that will be very beneficial for the effort. We already have a repository that supports the current CMIS model and JCR - Alfresco.

CMIS' goal is to allow an application to connect to multiple repositories by different vendors using the same protocol. Whether or not the application is thick, thin, or rich should not matter beyond leveraging the binding that is most appropriate. One of the main benefits I see going forward of CMIS, is that it allows ISVs that develop applications that use, consume or produce content a simple way to access an ECM repository from any vendor. Some of those applications will be thick and running on the desktop.


Al Brown
ECM CTO Staff, Information Managament
Office 714 327 3453
Mobile 714 263 6441
Email albertcbrown@us.ibm.com
CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation.

Inactive hide details for Julian Reschke ---12/05/2008 06:39:49 AM---Hi everybody,Julian Reschke ---12/05/2008 06:39:49 AM---Hi everybody,


Julian Reschke <julian.reschke@greenbytes.de>




12/05/2008 06:39 AM


[cmis] joining the TC, introduction, HTTP thoughts

Hi everybody,

so I finally joined OASIS and the CMIS TC -- sorry for the delay.

For those who do not know me already: I'm working for greenbytes, a
small consulting and development shop. In the past, we've been
concentrating mainly on JAVA based content management systems and the
associated APIs and wire protocols.

In particular, I've been a contributor to the IETF WebDAV working group
since around 2001, and have participated in the development of almost
all WebDAV specifications that came out after (DeltaV, ACL, property
types, redirects, search, ...).

The work on WebDAV also caused me to become interested in doing work on
HTTP -- there are many areas where RFC 2616 isn't as clear as it should
be with respect to *authoring* of WebDAV resources. It took some time,
but in the end the IETF decided to charter a new HTTP Working Group
(HTTPbis) in December 2007. We are now working on a revision of RFC2616,
and I'm one out of three editors. (see <

I have also been a member of the JCR Expert Group (JSR-283) since May
2006, and implemented the spec for one customer, leveraging the Apache
Jackrabbit SPI interfaces and the "JCR2SPI" implementation (for which
I'm committer as well).

The first thing I'd like to work on is improving the CMIS text that
talks about the relation to WebDAV. In its current state it is (IMHO) in
the wrong place (I think the comparison should be made with the HTTP
binding, not the model), and lacks some precision.

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.

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.

Similarly, WebDAV has *large* overlap with CMIS, some stuff CMIS doesn't
need (like locking), and some stuff missing (type model). On the other
hand, WebDAV is extensible, and WebDAV extensions for remoting JCR will
be developed anyway.

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?).

Finally, I'd like to understand whether CMIS is mainly thought as a way
to connect document stores, or whether we expect it to be used for
client (desktop) integration as well. In the latter case it would be
good to understand why we're doing something new, instead of extending
WebDAV which already has broad client support.

Best regards, Julian

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]