Re: [Storagesync] recent issues discussed (html)

Jakub Moscicki <Jakub.Moscicki@cern.ch> Sun, 13 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 DF2901AC3BE for <storagesync@ietfa.amsl.com>; Sat, 12 Dec 2015 23:57:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.599
X-Spam-Level:
X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, SPF_HELO_PASS=-0.001] autolearn=no
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 DFcTjUrY-tOP for <storagesync@ietfa.amsl.com>; Sat, 12 Dec 2015 23:57:13 -0800 (PST)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0681.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::681]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF211AC3B8 for <storagesync@ietf.org>; Sat, 12 Dec 2015 23:57:11 -0800 (PST)
Received: from DB4PR06CA0006.eurprd06.prod.outlook.com (2a01:111:e400:9866::16) by AM3PR06MB050.eurprd06.prod.outlook.com (2a01:111:e400:8805::24) with Microsoft SMTP Server (TLS) id 15.1.355.16; Sun, 13 Dec 2015 07:56:52 +0000
Received: from AM1FFO11FD018.protection.gbl (2a01:111:f400:7e00::183) by DB4PR06CA0006.outlook.office365.com (2a01:111:e400:9866::16) with Microsoft SMTP Server (TLS) id 15.1.355.16 via Frontend Transport; Sun, 13 Dec 2015 07:56:52 +0000
Authentication-Results: spf=pass (sender IP is 188.184.36.48) 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.48 as permitted sender) receiver=protection.outlook.com; client-ip=188.184.36.48; helo=CERNMX12.cern.ch;
Received: from CERNMX12.cern.ch (188.184.36.48) by AM1FFO11FD018.mail.protection.outlook.com (10.174.64.207) with Microsoft SMTP Server (TLS) id 15.1.346.13 via Frontend Transport; Sun, 13 Dec 2015 07:56:52 +0000
Received: from CERNFE25.cern.ch (137.138.203.208) by cernmxgwlb4.cern.ch (188.184.36.48) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 13 Dec 2015 08:56:35 +0100
Received: from CERNXCHG51.cern.ch ([fe80::20f7:8173:2da8:398a]) by CERNFE25.cern.ch ([fe80::2cd7:dab6:37a7:ce81%10]) with mapi id 14.03.0174.001; Sun, 13 Dec 2015 08:56:35 +0100
From: Jakub Moscicki <Jakub.Moscicki@cern.ch>
To: fsong <fsong@bjtu.edu.cn>
Thread-Topic: [Storagesync] recent issues discussed (html)
Thread-Index: AQHRNOef7oC/x3UBPEaZ+1qHcoBay57IfP8A
Date: Sun, 13 Dec 2015 07:56:34 +0000
Message-ID: <41F39F50-E49A-4C2B-BF09-B182580008DF@cern.ch>
References: <CAO_YprZTz+O-e82hsTgMBOLr645jJqbhtVKngubnLhimyfB2cg@mail.gmail.com> <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn> <CAO_YprbsHsDYewHh38uDJ6gOoSZKwO8MoCR+UHz21iarEqEQOA@mail.gmail.com> <2015121222163146812636@bjtu.edu.cn>
In-Reply-To: <2015121222163146812636@bjtu.edu.cn>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [81.28.197.96]
Content-Type: multipart/alternative; boundary="_000_41F39F50E49A4C2BBF09B182580008DFcernch_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD018; 1:0oT9fX1t3IJBwEVrDsewL73LFdl5cnOC+PbVIqVkNQ/UwDsL5Q4Mu9+oYrVdbICJv3KO1uBQtADHwlSMYpMx0upWbIGLR9wSELhtl8xfJqxhnuVaFl7GOlrkWAanFdb4GWXqASViy5nH2z15oWhBVNNf1hyguY5Qt+mkBcZp0Xft+o9ReJttdj8IRKB48iptBbSEMrzhu72HJcbx/pEusdk9Pg27H4fPUf/PYf9U3GvKFWp5CkgHk0Xc0oiaaR4ZOeoUe+FKj8XnJfCObz9b/w8rKd29RYoPimDAoqZxdClbv5Dd4gN4n4kcKQXt8Ch5ZxnxlLuiG/hL26/Tg5j1qquCM/fcGSxyve+5oNC4g1jbR6pDq3J3nPHAvp+b5s0YYGNcD+/fDbEtmwDjczDsVREE0BziyKd5CsCcLkWBc5w=
X-Forefront-Antispam-Report: CIP:188.184.36.48; CTRY:CH; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(2980300002)(438002)(189002)(199003)(24454002)(243025005)(1096002)(76176999)(54356999)(83716003)(86362001)(53416004)(19617315012)(16236675004)(106116001)(2171001)(87936001)(16796002)(93886004)(5004730100002)(106466001)(82746002)(92566002)(66066001)(2900100001)(74482002)(84326002)(11100500001)(15975445007)(50986999)(2950100001)(3846002)(1220700001)(26826002)(102836003)(189998001)(19580395003)(5001970100001)(36756003)(15395725005)(110136002)(5008740100001)(300700001)(6116002)(512874002)(5003600100002)(6806005)(586003)(5250100002)(19580405001)(33656002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR06MB050; H:CERNMX12.cern.ch; FPR:; SPF:Pass; PTR:cernmx12.cern.ch; MX:1; A:1; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB050; 2:lOasew/Kncrj2pKAErhTjPpaPwJEJUfzrv1oNTaZatfoClsvA8p39O/iK8JJPC0CecolNVmhHEQYpKXR2Nx+VN+sWLY+l1RnF3pCN4j+QDYh5KeikEOhV7grlZRkn/sEiZmp1ndh96o3/8ThLiXK6w==; 3:cLg67OJt0CatwE/lepxEH0cJQSOOjD9ZsQpo+4SPEPKYNNSoEY08UfiLBp6ZrPD7gWeylXeKeuUmHmQPMgYt+k0o+fMewhhsSh0ztFfzIKpuI8MgibFMCUXyMQZB3tPtTZkccvxL9UORyhswFRLXL13cjwYN2aqJCNsqZ2Z5We59D0PJPZqe7uXWw3hmXQyrhrEQk7ZTUkHMiX69YIAzpSfRKrZ4q6akIBiAFIJkgQ/yig2t6CPFWFrK3yrsi3QssdDUMuQpZET7JlhoFFu1vw==; 25:fCFBojaqDAvtYSkUJ+P0mq5wJqbpEmB3B46Nz9jUC5vEDlMmHdvAWJWrasgCdaP4hMewDT5SYb50vnfwX1RXRf132qXij9TnOpQHXj4opWLAxztnGqYEG6gr+v9Qv/kM2fk1bYj9+RKJCdzMB7ThzE1lH+/ZCOz90/KRVXHzBjsCZPu2blgvygcV4tLqmRyaeRP0rPN3D+h5Jt9mLXi+RPMBotkKJTlbf1GG/Qp1nxAWGVhgWg07Vtbxn7GZ4NP6cF4MYI8i2JK5n1EpPa+ZeA==
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:AM3PR06MB050;
X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB050; 20:sBbYyyNAXZHfTaxqPWdDG6PjaqfGfRaoNzYdrnmSgxyDe9srD4HEjlwlui38AKuSoB6J+OJEjswWBxBZCryYsS4jeTARKwjhe4O0nFghluGs0l9A6bpxHzTi/bLq0h81wtIdfFzLpR1q3zYr9kQtNVF//mR4sG4xNITru6vGHExr9Sce+CKHi/EHgCXssP6bjhIJj2mLFAxZ1oIh1C2mjxlieLJQ0iiIsvY2rz743RO0JfrL70033KB0tb0PDctAZnRLOZxKUQmgFXS9RQBb5OkB/R0+1gVLXWhAdiIiIy1/gDujs9dyJ9mKm5GmUOUkEPltYe6YDE1G2oe+E9u2tIh1VWFnqvu9EK1XwIO8aXVSwAXGRtO3NBRYlZNm3t42PVXfxRyzp0VmCUOxb65BCVefQr7YDOxiNN9Nvux5bquguPglvcafbhQS3E8dMJ/wSvdUTVsN2hwKCEj7XSwIE2FRCXEiiae7TuVauIONiNwSv1yhmjI+9W/TALH58yQ+; 4:PafApNgZWTnv4tH3L2hAWxSAEMYqYNN/oIj1u+BjSGrSEmLcLOMxi8+EUzhuFkpvjZLj6uFMcGI1VMcNSyYp8fVmqSgVrA7dMULTVjS/bxc95CKxc8ND3rxjbIPArOt94jIpvJrQPC5KmZI2SyCGUAlrz8ezXcBb3eJFIGR8RVkHeLBnTLHJ0p4i6SgZ3SkEaeMeP+vokhklLGlv+Sqvi6drvmSc6NxJ6TYgMwPYsyNQFFYuE0GlpLzcr9BedxxrgAkLg0MynTcKb7AFPjCwM710JOTl7IZd5BH59H4DSQ4REXXewK+mVtl/80XAd7FfbNUzLYxvsfppij77d1GM2u4fLR2lqQL6XiNGt9YEVhyWKAtatozjq9WzTi64kr57WCVyUAo2yzMhiHRMYJDlFF0OHavxc23WJZebYxQBKyyHbgEpcY4ZzELwjh3/N2vE
X-Microsoft-Antispam-PRVS: <AM3PR06MB050FC75D921243E1B2F262F86EC0@AM3PR06MB050.eurprd06.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(109460225580195);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:AM3PR06MB050; BCL:0; PCL:0; RULEID:; SRVR:AM3PR06MB050;
X-Forefront-PRVS: 07891BF289
X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB050; 23:tEvzs0Hdfuub+WnRx8xa13qzGAvfjMIiRWiyRggDmaJv3Rlq0ZG2sg8NjRNucAsHnkJKIxfLIWPcRLMve3fSpb3qZLjOLdf6rRlL0TgxScWwtjMeVznRtc1y0Gsura5/762oxASEhdTIZQGoauvoYBdjPqflj0YV2Al3OTXASD3AGUOpjBOU8bye6ZsFs12KWUCBZuc1Z0sbzIyyjUctXsXY7Zj4NaNPxcPfk8JUi43ZNeJmKTWA3iEku6cEjhe54rvV1ZcLzMR7flmcjRyw9utxbxmunmijNEiiJWj2kjHoF1zPjObRurTV5wkEN2rcZBe/A3AiD2QFAuddi7g4/o6IxqhRqDESbgzasH9thaNHFBBKvF0z/eRqxcxzkY5NwiBLME2lC1XvJBAR9fvoHm4XLtR1au+lhmOehma55UTp1BG6/YzklIeaF52XInqg5c9C2BNB7rqol2wYA/o7c+XY5n1UbSW4DQdbtxTJci7/lKgrUfNPucSd8F5gnN1Bl495XAra0o/326DOuOH2Zi/YzappJToKPMnMoXYLIJkks1JNpJCNpHIm11kF9yKLWTPeko7Ed8Om8tA5w/TBpgHhBHgQZFY5AhQzGZ3shNRdgpuJKZpO/xMC7vNKkiNEq1FtkK8n1susmRQPmBnMQNBlKUOHbcl5n+SeH+CODxdba+Zq9LpEyc3kvbtXYuqaciVh0TDETRCcOA8pGjCrEY8UzGYdlpD7eEYdoAdpR+S63UCAiPu97VBrT0ta5i+gnzYmKR7rjBhLVvBx9cAK44aqDeISPDnz74qrXWIl+SNH/KaLhCiI9PXX/doLKnEBYaIfk6QeeHf8btmuvywXZESNdFF71vlFiA7xYKW2KW8k8rdvNhDjJWp38XN728tatJQRHkgIGn++UQMZ+e16+9fh9DAmvBOtS994wef7rI+xkhGUTW95QFFBdwOokTIxkyZlq+e9r33Xx6g8A/ByaWrYr5/S1ax4pyX0Uerow92A0sqr2qvigbby40dc3NJTcDkBr3TBf8rLK1DYi5NbGBVTog7e4mzQm2ZjLfQL/3b7mdvHOVDgSjqqHFVopBq8w6VYiV9kwAiH5ZwOX1EY9ZDkNTbKL8KSEUgIhZitXr5BiBjZKu2D0l2oKlKJFe0A/5zuDN47e4WcRxbjMZDASHkb5TdMutDwWL7WIj33VtBaF9Nqlle/a1+fgWh4UTa3IB6IOlWRFk4dJrcsJnccs3yGM1Pt+uwft7nVhvF5FKLUZpImsQ+yxLWehhOOM4LSse8iWesYxMM25E2JAYuyEQ4FQPYzVEnEkrW7BPZTZuTTMM6ggxNcDlzgbH6JqzyH1WxM9bcSQIuLUUWbfUFAcQ==
X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB050; 5:nzXrGGNdoG0KrLmaHoEVQat8yEALPXIfqfN1wSMNIgUpVQJU6hZAJR6e7iF/rjWblc0UZcVreJ912OY3kxBQ3GUOTTcjGp3XrcQ5xQ61SBHV1Eg618mVOINZpMEDmm3ac8nc5NwABBCECVxPY432YQ==; 24:wLjMjZIhicty+E6aYIywBaPg5Yu1Ysn1OmdUxuzUw1t9OvFOiS5MUcVH3+RhBBOokl04OI5A3sXhjaNPoJM/fYV69eXhRfMab3HwFEN/GKc=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: cern.ch
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2015 07:56:52.3106 (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.48]; Helo=[CERNMX12.cern.ch]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR06MB050
Archived-At: <http://mailarchive.ietf.org/arch/msg/storagesync/4L7XV4a-qzNuKsnMHAb-RHObQDY>
Cc: storagesync <storagesync@ietf.org>
Subject: Re: [Storagesync] recent issues discussed (html)
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: Sun, 13 Dec 2015 07:57:21 -0000

Hello,

You may also consider to add to this list this de-facto sync protocol description used by owncloud sync clients (and some footnote discussion on future development directions):

https://github.com/cernbox/smashbox/blob/master/protocol/protocol.md

This document comes with a test suite (partially implemented) that verifies if a server adheres to this specification.

Best regards,

kuba

--


On 12 Dec 2015, at 15:16, Fei Song <fsong@bjtu.edu.cn<mailto:fsong@bjtu.edu.cn>> wrote:

Here is the latest version. Please email me if anything is missed:

1.         The design targets of WebDAV, rsync and other existing approaches?
2.         The potential use cases of ISS, such as client/server, git-like pattern, svn, etc.
3.         The efficiency improvements might be the second goal for standardizing ISS protocol
4.         CORS headers on storage sync APIs
5.         What is needed for the ISS: a sync protocol or a generalized API
6.         remoteStorage draft discussion
a)         relationship vs WebDAV
b)         MOVE action (synchronization) should be added or not
c)         Beside web browser, desktop apps (by hacking way)
d)         comics of new standard
e)         etag issues vs metadata
                         i.              is mainly for identifying whether a document is changed or not
                       ii.              is easy to implement than that of WebDAV sync protocol or not
                      iii.              the metadata file contains all etags for all files at both client and server side or not
f)          the distributed peer model (no server) and C/S mode
g)         a fancy example (with pics) of OfflineIMAP’s sync process in following URL
http://blog.ezyang.com/2012/08/how-offlineimap-works/
7.         GitHub (instead of email messages) has been created:
https://github.com/labkode/Internet-Storage-Sync
a)         What is the topic?
                         i.              Whether it is suitable to build on WebDAV
                       ii.              WebDAV vs remoteStorage
                      iii.              Advantages vs disadvantages of WebDAV
8.         Metadata and data separation scheme and platform for synchronization
a)         ownCloud when configured to use an Object Storage as the Primary User Storage. (Metadata is handled by a MySQL database)
b)         CERN EOS Storage System. (Metadata is handled in high performance in-memory structures).
c)         DropBox. (As far as I know it uses S3 behind. For metadata it is unknown, but probably not on S3).
Paper for analyzing DropBox:
http://annasperotto.org/papers/2012/imc140-drago.pdf
d)         ClawIO will have an implementation of this approach in the next phase using Swift.
9.         Whether we should keep metadata history or modification history or action history at server side (or other places)
10.     How to handle the “conflict discovery (resolution)” issues
a)         A good demonstration of this issue was given in details (File F, Client A, Client B, etc.)
b)         Should it be a layer above syncing?
c)         Should it depend on the use case?
d)         Should it be a one-size-fits-all approach?
e)         How many different kinds of conflict?
                         i.              File level conflicts, e.g. both remote (server) and local (client) have changed since last sync.
                       ii.              Interleaved level conflicts, e.g. one client makes a change based on version X of the file, a second makes a change based on version X+1, the second one commits, and then the first one commits.
                      iii.              …
f)          The sequence (order) of changes in one file is important or not (quite similar with “item 9” in this list), perhaps depends on the file type (or use cases):
                         i.              It may be important for: sound file, drawing file, latex source files of articles, iWork files, Office files, images, pdfs, source code, etc.
                       ii.              It may be not important for: Physics data.
g)         Whether to enable an automatic merging might be a research problem or a further use case?
h)         If It is so hard to do conflict resolution even for simple and well-structured “vcard case”, should we handle this issue by separating files based on their property?

Some related organizations, events, projects, etc.:
GEANT community, OpenCloudMesh, ownCloud, CS3, remoteStorage, ClawIO, crosscloud, Dropbox, CERN EOS Storage System,to be added…
_______________________________________________
Storagesync mailing list
Storagesync@ietf.org<mailto:Storagesync@ietf.org>
https://www.ietf.org/mailman/listinfo/storagesync