Return-Path: X-Original-To: apmail-chemistry-dev-archive@www.apache.org Delivered-To: apmail-chemistry-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D0F55188E2 for ; Wed, 3 Feb 2016 08:57:22 +0000 (UTC) Received: (qmail 21525 invoked by uid 500); 3 Feb 2016 08:56:48 -0000 Delivered-To: apmail-chemistry-dev-archive@chemistry.apache.org Received: (qmail 21464 invoked by uid 500); 3 Feb 2016 08:56:48 -0000 Mailing-List: contact dev-help@chemistry.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@chemistry.apache.org Delivered-To: mailing list dev@chemistry.apache.org Received: (qmail 21451 invoked by uid 99); 3 Feb 2016 08:56:48 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Feb 2016 08:56:48 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id F4188C1BA0 for ; Wed, 3 Feb 2016 08:56:47 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.281 X-Spam-Level: X-Spam-Status: No, score=0.281 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id tSAySrvNCeSk for ; Wed, 3 Feb 2016 08:56:46 +0000 (UTC) Received: from plasma6.jpberlin.de (plasma6.jpberlin.de [80.241.56.68]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 5333721150 for ; Wed, 3 Feb 2016 08:56:46 +0000 (UTC) Received: from gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) by plasma.jpberlin.de (Postfix) with ESMTP id 3CD42B0D87; Wed, 3 Feb 2016 09:56:40 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from plasma.jpberlin.de ([91.198.250.140]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10024) with ESMTP id 06P1HIArAeth; Wed, 3 Feb 2016 09:56:39 +0100 (CET) Received: from webmail.jpberlin.de (sinatra9.heinlein-hosting.de [80.241.56.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: fmueller@jpberlin.de) by plasma.jpberlin.de (Postfix) with ESMTPSA id 2D2E4B069E; Wed, 3 Feb 2016 09:56:39 +0100 (CET) Received: from 67n2EpreXWz7QHvtDhJ6tRM3Or1PTEDnChxA9fxZ+HA= (Njq1OwG3jGJaddL1NRhEHUn/5ropHx88) by webmail.jpberlin.de with HTTP (HTTP/1.1 POST); Wed, 03 Feb 2016 09:56:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 03 Feb 2016 09:56:39 +0100 From: =?UTF-8?Q?Florian_M=C3=BCller?= To: dev@chemistry.apache.org Cc: Srinivas Nv Gannavarapu , Randy Richardt , Jay Brown , Yong Liang Li Subject: Re: A better way to add/remove hold in CMIS 1.1? In-Reply-To: <201602030826.u138QWGI007232@d23av03.au.ibm.com> References: <201602030826.u138QWGI007232@d23av03.au.ibm.com> Message-ID: X-Sender: fmui@apache.org User-Agent: RoundCube Webmail Hi Mike, I hope I've some answers for you. Re a) Holds are stored as a multi-value property. CMIS only allows retrieving and updating multi-value properties as a whole. There is no support for partial retrieval or partial update. But if a client doesn't modify the list of holds, it shouldn't send it to the server. Hence, there is no need for the server to retrieve the list of holds all the time. Do you except a frequent change of holds on an object? In the use cases I know, holds are not updated very often. Re b) That shouldn't happen if your server implements change tokens correctly. Change tokens are supposed to prevent lost updates. - Florian > Hi all, > > In the current CMIS 1.1 spec, hold is supported by secondary type. > Specifically, the user can add/remove ids from cmis:hold.rm_holdIds to > add/remove holds. There are two major issues here. > a) The user need to firstly retrieve out the whole hold list before > the > user can add/remove hold. The list might be a big one depends on > business needs. In CMIS server side implementation, we need to > firstly > retrieve out this list from content server and compare it to the > list in > the update request. So that we get to know which one should be > added/removed. Even though there is no change in this list, we still > need to do the retrieve and compare practice in each checkin. This > will > not perform well. > b) May result in inconsistences in consequent updates. For example, > user > A is trying to add a hold, so it pass the original list plus the one > that it wants to add hold. Now user B wants to add another hold. If > user > B's original list had been retrieved out before user A completed the > update, then user A's update will be overwritten by user B's update, > unintentionally. > > > So, I wonder whether there is a better way to add/remove holds without > going through the retrieve and compare logic in an update(checkin). > Thanks > in advance! > > > Best Regards, > > Mike Li(李永亮) > IBM Content Manager RM Development > Tel:(86-10)82453403 Fax:(86-10)58851920 Tie-line: 905-3403 > liyongl@cn.ibm.com