Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1

Jakub Moscicki <Jakub.Moscicki@cern.ch> Thu, 10 December 2015 07:57 UTC

Return-Path: <Jakub.Moscicki@cern.ch>
X-Original-To: storagesync@ietfa.amsl.com
Delivered-To: storagesync@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3931A1B1C for <storagesync@ietfa.amsl.com>; Wed, 9 Dec 2015 23:57:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uqiW1bUiBaR for <storagesync@ietfa.amsl.com>; Wed, 9 Dec 2015 23:57:25 -0800 (PST)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0677.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::677]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E3C1A1AA8 for <storagesync@ietf.org>; Wed, 9 Dec 2015 23:57:24 -0800 (PST)
Received: from AM3PR06CA057.eurprd06.prod.outlook.com (10.141.192.175) by AMSPR06MB072.eurprd06.prod.outlook.com (10.242.90.152) with Microsoft SMTP Server (TLS) id 15.1.355.16; Thu, 10 Dec 2015 07:57:03 +0000
Received: from DB3FFO11FD040.protection.gbl (2a01:111:f400:7e04::144) by AM3PR06CA057.outlook.office365.com (2a01:111:e400:882b::47) with Microsoft SMTP Server (TLS) id 15.1.355.16 via Frontend Transport; Thu, 10 Dec 2015 07:57:03 +0000
Authentication-Results: spf=pass (sender IP is 188.184.36.50) smtp.mailfrom=cern.ch; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=cern.ch;
Received-SPF: Pass (protection.outlook.com: domain of cern.ch designates 188.184.36.50 as permitted sender) receiver=protection.outlook.com; client-ip=188.184.36.50; helo=CERNMX11.cern.ch;
Received: from CERNMX11.cern.ch (188.184.36.50) by DB3FFO11FD040.mail.protection.outlook.com (10.47.217.71) with Microsoft SMTP Server (TLS) id 15.1.346.13 via Frontend Transport; Thu, 10 Dec 2015 07:57:02 +0000
Received: from cernfe06.cern.ch (188.184.36.49) by cernmxgwlb4.cern.ch (188.184.36.50) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Dec 2015 08:56:48 +0100
Received: from CERNXCHG51.cern.ch ([fe80::20f7:8173:2da8:398a]) by CERNFE06.cern.ch ([fe80::64b8:95fa:42bc:1ef5%11]) with mapi id 14.03.0174.001; Thu, 10 Dec 2015 08:56:48 +0100
From: Jakub Moscicki <Jakub.Moscicki@cern.ch>
To: Klaas Freitag <freitag@owncloud.com>
Thread-Topic: [Storagesync] Storagesync Digest, Vol 5, Issue 1
Thread-Index: AQHRLH0+7gCKX1UFx02QDZgdWy/v7563OhsAgAArgwCAAAZPgIAAAsoAgAAiFACAAVlOAIAACqEAgAACRoCAAAS6AIAAC86AgAAAVQCAAAIgAIAAPLWAgAHN3gCAAA3lAIAB4XiAgAAwgYCAAPsvAIAAb/IAgAAAzwCAAAM9gIAAAb8AgAADTgCAAAE9AIAABBwAgAAHaICAAAtbgIAAAxyAgAAesin///WngIAAM7sAgAC71wCAAP3bgIAAgq+AgAAjBgCAACjcgIABKcH+///yNgCAAAPMgIAAbzkAgACzsAA=
Date: Thu, 10 Dec 2015 07:56:47 +0000
Message-ID: <A639311C-A08E-4E7F-B317-FDA14224CAA3@cern.ch>
References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com,> <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <CAO_Yprbct8wFbS1WFnZZENSp-OruRUk2nRyBv4tNeKv9_CGuCg@mail.gmail.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <CAO_YprZjqs_OFC3RybVvJ4GHWb3spKMMkkFTZO=YDustp825iw@mail.gmail.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> <AE0CE9F1-3968-4229-925B-75AA37EDC327@unterwaditzer.net> <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> <506D291C-4F0B-40F3-8848-97DAAF41CAAE@cern.ch> <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com> <56689982.3040901@owncloud.com>
In-Reply-To: <56689982.3040901@owncloud.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:1458:202:225::102:5ec0]
Content-Type: multipart/alternative; boundary="_000_A639311CA08E4E7FB317FDA14224CAA3cernch_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD040; 1:hFfbhceODRvWiAtXWhuO6TSbX4Fd3AGbTRos8Lr9MOacr3WVmB8BhDUbL/m2AWmUhJJwfHLXpeP3hy6M/jZ02bDL/TQeNbNSZpJu9Rd/lIJ0jaiUut59RjsvJK7UwQ03KlV5fLKaDM9pDWoUeA4kP8jomSXbR4O/7z3HJwyejg1Y6smIjvwKTi/kILKKDks4Z0COFsAdfdnVMbCg3Y0dSKPFZqm0unpkknCnpUBw81okU0CBPMm6v07wYAMEkDTaiofgKAG0d9sonhheS5TzXDUilUqL1GzPu5ERkr0/qDDeD0mspwgxuu7iWNVFENT2pBHeNqevv8YV46Qcb6b3rWp80Uirc3qzMM3bCK+5l/+uGx3rbnZLtKEc8S75cPJFQU9M8flsBIFgcFsQDsxFPX3xqJP3hgD8CSavGiXswkA=
X-Forefront-Antispam-Report: CIP:188.184.36.50; CTRY:CH; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(2980300002)(438002)(5403001)(189002)(18543002)(10533003)(199003)(2950100001)(54356999)(5004730100002)(16796002)(586003)(84326002)(102836003)(19617315012)(6116002)(83716003)(87936001)(11100500001)(82746002)(6806005)(300700001)(1220700001)(1096002)(5250100002)(5008740100001)(86362001)(93886004)(106116001)(106466001)(76176999)(50986999)(2900100001)(110136002)(5003600100002)(189998001)(92566002)(16236675004)(5001970100001)(15975445007)(74482002)(26826002)(33656002)(512944002)(36756003)(19580405001)(19580395003)(53416004)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR06MB072; H:CERNMX11.cern.ch; FPR:; SPF:Pass; PTR:cernmx11.cern.ch; MX:1; A:1; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB072; 2:UyXcQ2xwm4O5tXB+ZV+KviNF9+hEQKpXBBhawdVrvacTnVVAI3ZpYNFstJVqEsGXEZujrB9X0AVBlY5MDfYbk80EkF44vgbWqJp3Sh/IqPtNps2aS+IBbWs4kCiXZ+xoeOTwffQANmdeUszJ1eGD2A==; 3:3dJbA9SF6S6QysrqUlJLfLmheytFvdAo7lPYd4HbHohCGzGGaHm5dzIwbfI6gBZIf2bp27+TNl8ZO7/Swjit//o4NnS9txD3fC8Zq0cZy/JgoNNll56Nw91mkstp8JN/ygB9VdTLGEYO3RSe7KwyGMmxFa+zsbRCQEbUZ+CLw6a4ZquofWQqZrwr2678QW3+oUtbUdx1wKZVTfpJKjQqoLnwwbrGzelZD5kABogmpDfYCGMn6eh9sjj5ouKYil0UB8TOIDHcZqQ7I+mlqCEWhQ==; 25:p2Au4VPIA+J4SzTBnJxasZ8q3TpCg3er3/EeMnN3qaD8ZRoSmLRKnuPONxG/tCZEF5BtCr9hzwpveDUFNhZEq7CJqTyjaRSUicz3FtPswHtnwcJvBk52W0iuOyxdUhbzl4Nf3UvHQCChN7TwDTZoXRJSjTzfzojwlTjfGG2ebDERneCEGtY6KTYS8FnRhp7C1K4rxOmUHivLwURQglW29BPJlPiwAgvCeSCuMRkpCB8aRjvfkx9R/9NrgWdHO6aEgaRGAU/60C1Lk3ebPSpoyQ==
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:AMSPR06MB072;
X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB072; 20:b+kEgtg39RWgHO5+CIU0O7kHDP9ek20GLO+IUp6uoEwUUeWVhgWoKNrBdvoq1rPrxRQJn7KBUoFRrOx+1BJex2N+4zXVSIXzg/xR5Vo3+UREpMj1z+Zp9u1jecGOvLoUcO4COESuZoW5J6X/IANPeS3CszTfXWexgBTE2asU6NfGNBFxzzzU/pmXT6w94shgdf56EyZlI3uLK1bYJVtl+yxdClontvY4TdwxP6+0wC9hqGfxNW+KHBr3wnM1pTx9CZ5fRAEfsowasPD/L7cEARCOMFuBGQrYLr7NMAGmpFMh2mh+HT9oDAYrPMej90Q5G5mTc8YX3M553TCZWiqkebAXJxs/JT/iWerneEGk6k73//XqKgzruiagUGwIzfsmnas+2Ww7ZFe7DPAYOUvAuz0E+DMtr1SXsgI4LyZyfBUwSrRNhY2A35NjghmqBXmfpyrTm3ZUk809VXh4azLI6hkVNpckPL/WNy6Ako8B2uhn3Ob8/L7+ueLf9z4eKFJK; 4:/NA7oVdqTF+RgphLmZLh6X0r/HiXoKuS96wYftE7eoR4x4QAJhoiHRw4TGCtFpSH2bkkLjOOUAov8A5eBkLidt0T2BWK7ayggBUQgN+gUaUKeKeqtp1+9pKR6R3XL7BQGBS3hMG5+QYmmyVH1FAfIRKf0V10JGEJcIVkoDlO6Up0xYJmCFpmZotP1NtirnPyMYWzBlGJTJ/rZToxOEXrcRTyjvZDIhpMIKyI1y6maLRu/prUf1Ur8iW5b988s3ek1i5GUaQwqR9lJq8yiXSdIsAtUYBGzRoya/s2wMfU7wA29/GEqfK58J/1ThfXQx4OPJBaw/JC7qvhw/jhux5o9aJ5ESQQWmpjEXDqoBh6dSpG6LGuJh4qXf5DJrlZto4vjTZUv3SaMECOfJ9vUyKaC784CT4WZcUMjIJ+DO1xnPAHDNAzCia0X9Wry1j5Q02I
X-Microsoft-Antispam-PRVS: <AMSPR06MB0726C313AFF59F5A70DFC5986E90@AMSPR06MB072.eurprd06.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(109460225580195);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMSPR06MB072; BCL:0; PCL:0; RULEID:; SRVR:AMSPR06MB072;
X-Forefront-PRVS: 078693968A
X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB072; 23:ayKolb5NNIf31TEA8stSBRC5F7R97kBkyWM7nOLptUHou9SG5N5VimphLgof0ul5L43K6oA5RAaFn7E8buICOte66tIg0NK/9Y1AxDNSLB6kNcxC4AzIlzQCaSJSZdjDFjprVnIgVI2U4ciOZCB4NfoTkV44+UwFCe/690gYXXqYX7I2pxkQHFRt900JHjjVmCtPuPUir1hG+91j4aK0VD/XJc3vUvkRZ1I+/sy3CxQXnU154ESbtLrZB3/LANpeX7Y3cdGGQIgtpU/1ddI4bL9gx2HFqD1ctaDd89pMnj9wjgEpkWxJYjl5kKRD+iA/GEcualcWXWR7y2+yi+57NecCQNvlqOxOzBC46qRZAsb5TY3yAqdp5nntNPpCalMEMJpel8Stj65bxSLXJNTP0Wd7mg8pV71ERiUDiLsMLFj2xnZzi52yjZ8GnrLARsfkJr+lFfFNmOOoRNIJI7AZ7/x1gY9BmoUPSmQ1mpLNZkgpIU4ijasEkk/jGwRNbrLgO2f5jasXDOpv+eJwzRZMrqh8B68bbQCh9jLtYAnAtWyzk4GHB0CKW4USLfr3RI7sRHt+LAlaPLxPhGIs4nUtHL69ZULREtCcucYDi31XhjTofXMgfO6jWOxhQ2JcQzmvtFxzZg4hYgcY3jxVxfwbm39BdCx3jzIfVYO/DGRG1o7LvDIeh2nQo6cR8byKfQhaAAOqqB97GjCsEH+MvqXS2VPK+IRjN8A1Tvi8HMosubbKESiaJf4RrEtZOhxfHf0cFv8NS4/NqjsF3L5BA859MT7QL9fdPQoM3rz2Eklc52NNh3FOr5bEjb6n3BlVPadMIcNpmcy+DrAGnDg3ZmL1MUVY/bjTjAKrhurKN5nFCE96P2aB19B2gd+n1O7tGexaIz7+NCIQLoZ9hbA2T6MSzo9zqlr+m7F6hfHdn53EL3rfi26AAjsWLZmjBTn+S3oaC855+Xp+AvUkNC71afn8CNO4CEzf22/ktdi2E2nIGOO7HEII4RhvD4p4FkQhdRzyyK+vobfarYFgoVwngzwQf2IyZy4/I5iL9UUkfJ9rrspIiuEGbNflmYOQxdFufxj+hAPEhoZdX9iX86jkh6NuUPWb1t4TmceI2iHckFrM7shOc/PvNrZMIqhFtNbS631bGsnzmTC1rzUTxjT48GZI5COcDKQk7Ug+ZSdZeSJto55b8qonmXb8/87R6YjmcPg9rpEnMBSUKh3pharvNy0zfCxjHE3wtZLA/4O/GW7KZZctrDmk6qyjBYjaUMsAY8pnrq1BINZu20oo3zTR8+vgneYwwPAlbij7bAxOXMEFnCU=
X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB072; 5:mbDEo2AS90ZEg2jTqHgr2S/nZjBsRI6LTdJ7TFWDIOp8VNJvpnYmQjBQweR1wLOJSqiw+gAcnmcbqEwu49EsGAMBK3DKNeoOX8IwJyaT8OkLdGYJE6o1DuQ01//SvvImv3Rso+bxteeUnWnK5JQ6bg==; 24:aKPY131PtoSpFuorwsXl6E2+bek+W4VchgH0NE1vXI2e6qtCP/yDkPNVas2J9YWOk8wF+Vz+4A2WJoRD1T2mjbxBGSGWTm+9rJ23prHKUVw=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: cern.ch
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2015 07:57:02.9810 (UTC)
X-MS-Exchange-CrossTenant-Id: c80d3499-4a40-4a8c-986e-abce017d6b19
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c80d3499-4a40-4a8c-986e-abce017d6b19; Ip=[188.184.36.50]; Helo=[CERNMX11.cern.ch]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR06MB072
Archived-At: <http://mailarchive.ietf.org/arch/msg/storagesync/0irmKhhbDMLSfv7XTyJUW3k0D8M>
Cc: "storagesync@ietf.org" <storagesync@ietf.org>
Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1
X-BeenThere: storagesync@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services <storagesync.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storagesync>, <mailto:storagesync-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/storagesync/>
List-Post: <mailto:storagesync@ietf.org>
List-Help: <mailto:storagesync-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storagesync>, <mailto:storagesync-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Dec 2015 07:57:30 -0000

Hi,

Automatically mergeable or not, I don't think resolving conflicts shoudl
be part of the sync protocol. Of course conflicts must be detected and
hooks should exist to plug in code to work with it, but I doubt it
should be part of the sync layer to interpret and resolve them.

And even if there is an automatic resolving of conflicts for some file
types (that is obviously possible if that is wanted from a higher level
point of view) there always remains the possibility of not at all
automatically mergeable conflicts.

I am also not sure about the importance of the sequence of changes, as
there are situations caused for example by offline work, where changes
happen in parallel, these cause a conflict, and it's not really
important which change was before or after. Important is that both
versions can be found again, but not necessarily in timely order.

I tend to agree with what you said above.

I do not understand why Kuba said "Etags are sufficient" in this
context, but maybe I lack context because I am late to the party…

Meaning:  in the view what you said above the opaque etags (e.g. md5 or uuids) should be sufficient as there is no need to reason about the order of changes or version numbers, etc.

[Plug: all people passionate about discussing these things should consider to come to CS3 in January and do it there :-) ]

Best regards,

kuba

--


regards,

Klaas



The absence of this feature is a serious problem in my workflows; I don't know if your experience is similar.   I don't really see any point in inventing "yet another" storage sync mechanism that doesn't provide this feature.   E.g., do you really want a calendaring system that automatically re-adds files that have been deleted on one client when a second client connects that hasn't seen the deletion?   An address book that backs out updates?   A mail system that undeletes deleted messages, or deletes messages on the client that were lost on the server due to a crash?

The use case of a small collection of large files used entirely sequentially is easy to address, but (a) not very interesting and (b) not actually a common use model.   It _seems_ common because we don't provide anything better, and so people make do with it, but it doesn't actually fit with what they are doing.   If it did, we wouldn't see the proliferation of manually-labeled versions of the same file that is so common in such data stores.


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mellon@fugue.com


_______________________________________________
Storagesync mailing list
Storagesync@ietf.org<mailto:Storagesync@ietf.org>
https://www.ietf.org/mailman/listinfo/storagesync