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] Investigating CHECKIN verb for CMIS



Cmis allows the repository to choose when the version history is updated:
1. At checkout (ibm has a rep that does this)
2. At checkin (enc has a rep that does this))

Ibm's rep that does this changes the state and security on checkin but does
not update the version history.

CMIS requires the version history to have the version after checkin but
does not require the addition of the version to history on checkin as it
may have happened before.
------Original Message------
From: Julian F. Reschke
To: Albert Brown
Cc: Julian F. Reschke
Cc: cmis
Subject: Re: [cmis] Investigating CHECKIN verb for CMIS
Sent: Apr 16, 2009 10:11 AM

Al Brown wrote:
> Julian,
>
> I thought I would also start a thread investigating CHECKIN verb as
> well. Upon reading, http://tools.ietf.org/html/rfc3253#page-38 here are
> some conflicts with the current RFC:
>
> #1 Request Body must be DAV:checkin. CMIS would want it to be the atom
> entry for properties update if provided.

So you want setting properties + checking in done in one atomic
operation? That could be solved by extending DAV:checkin to carry an
additional container element holding the properties (that's a typical
case of using the DAV extensibility model).

> This can be done if CMIS REST/APP does not want to support
> checking(objectId, properties, content stream) but rather
> checkin(objectId) - e.g., not information on checkin just the action.
>
> #2 The pre & post conditions are DAV specific and would not apply. In
> general some of them would:
> a - reflected in version history

Can you elaborate? A checkinop that is *not* reflected in the version
history?

> b - uri provided for checkedin version. CMIS provides an URI on both
> checkout and checkin. The URI could be new on checkout and then constant
> or new on checkin, or new on both checkout and checkin.

You're probably looking at simple versioning (checkout-in-place
feature), where CHECKOUT just flips a bit, and CHECKIN creates a new
version resource.

The CHECKOUT type you are looking for (CHECKOUT creates a new resource)
is defined in the "workspace" and "working resource" sections
(<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.6> and
<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.9>).

> #3 - checkin comment is not supported by CHECKIN.
>
> This would have to be modelled.

In WebDAV, this is just a string property with a well-known name;
shouldn't be a problem in CMIS.

> So, provided we wanted to write an RFC, we could get CHECKIN to work)
> with CMIS, but I think it is in the same camp as MOVE/COPY.

I agree that making CMIS + RFC 3253 co-exist is likely to be ha

------Original Message Truncated------
Sent from BlackBerry.



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