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: 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 <http://tools.ietf.org/wg/httpbis/>).

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





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