Hi Florent, Picture a query result set within our client application, similar to what you'd see in the CMIS Workbench. In it, the user doesn't want to 'see' the PWC if a document is checked out, they only want to see the LMV. So on checkout, we don't send the PWC to the client. To do a check in, we need to then fetch the PWC (if we're using WS).
Don't get me wrong, this issue isn't preventing us from delivering a solution. There are several easy workarounds, including returning the PWC as you say (but then we'd have to hide certain details, etc), returning the PWC ID with the PMV, etc. There are levels of translation between CMIS and proprietary document objects that need to occur which complicates it and I don't really want to get into that. Basically I just wanted to highlight the differences in behavior between WS and AtomPub bindings on the server implementations. They shouldn't be different. How this is reconciled I'm not too bothered about, as long as it's consistent :-) Tim On Fri, Apr 12, 2013 at 11:16 AM, Florent Guillaume <[email protected]> wrote: > Hi, > > On Fri, Apr 12, 2013 at 10:42 AM, Tim Webster <[email protected]> > wrote: > > This allows client > > application to avoid having to do another fetch from the repository to > get > > the PWC. > > I don't understand your use case at all. A checkin is an action > *about* the PWC, that basically requires rights on it, so in what > circumstances would a client not have access to its ID anyway? > > > One of my current business scenarios requires me to check in the latest > > major version (LMV) of a document (because we don't make the PWC > available > > to the client). > > Huh? Could you detail that? If the client doesn't have access to the > PWC then what is the PWC good for? > > Regards, > Florent > > -- > Florent Guillaume, Director of R&D, Nuxeo > Open Source, Java EE based, Enterprise Content Management (ECM) > http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87 > -- Check out my wine blog: http://timswineblog.blogspot.com/
