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

"Fei Song" <fsong@bjtu.edu.cn> Mon, 07 December 2015 02:38 UTC

Return-Path: <fsong@bjtu.edu.cn>
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 DD2611ACD32 for <storagesync@ietfa.amsl.com>; Sun, 6 Dec 2015 18:38:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.789
X-Spam-Level:
X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_PSBL=2.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 x7Hah_D-OqZN for <storagesync@ietfa.amsl.com>; Sun, 6 Dec 2015 18:38:11 -0800 (PST)
Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 9F30D1ACD30 for <storagesync@ietf.org>; Sun, 6 Dec 2015 18:38:10 -0800 (PST)
Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb1 (Coremail) with SMTP id Mp5wygCnCuaw8WRWNAAAAA--.8S2; Mon, 07 Dec 2015 10:40:48 +0800 (CST)
Date: Mon, 07 Dec 2015 10:38:08 +0800
From: Fei Song <fsong@bjtu.edu.cn>
To: storagesync <storagesync@ietf.org>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.0.1.91[cn]
Mime-Version: 1.0
Message-ID: <2015120710380820341179@bjtu.edu.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart267711440563_=----"
X-CM-TRANSID: Mp5wygCnCuaw8WRWNAAAAA--.8S2
X-Coremail-Antispam: 1UD129KBjvJXoW7Zr1fWF4rJF1kGFyrKr4kWFg_yoW8CF48pr WUGFyfGF4Dtr4fX3ykZw129340yrn8W3y7Jwn5Jw13t34rGFW2gF10kr15CrZ7W398GF10 qr4Ygw1UGw4DXF7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkqb7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr1j 6rxdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVCF0I0E4I0vr24lYx0E2Ix0cI8IcVAF wI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0x vY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxM4xvF2IEb7IF0Fy26I8I3I1lc2xSY4AK 67AK6r4UMxAIw28IcxkI7VAKI48JMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwV AFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUJVWUXwCIc40Y0x0EwIxGrwCI42IY6xIIjxv2 0xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4 v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E 14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU8qXd5UUUUU==
X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/
Archived-At: <http://mailarchive.ietf.org/arch/msg/storagesync/yGZQna4yJ4HgB_x_tEiYxu6f2UM>
Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1
X-BeenThere: storagesync@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: fsong <fsong@bjtu.edu.cn>
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: Mon, 07 Dec 2015 02:38:13 -0000

Hi Markus,

So, in remoteStorage, what should be stored at the both client and server side?
Etags or metadata or metadata history or other things?
based on the draft, it seems that only Etag is enough, but the context in this mailing list confused me...




Fei Song

From: Markus Unterwaditzer
Date: 2015-12-07 05:54
To: Ted Lemon
CC: storagesync
Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1
Etags are *much* simpler to implement on the server side than the WebDAV sync
protocol because they do not require the server to keep sync tokens and
metadata history. Note that the server has to keep metadata of *deleted* files
to correctly implement WebDAV's sync protocol. Etags are less efficient in
terms of network usage of course, but that's the tradeoff to be made.

I don't know what you mean with the last sentence.

On Sun, Dec 06, 2015 at 06:26:54PM +0000, Ted Lemon wrote:
> Sunday, Dec 6, 2015 12:39 PM Markus Unterwaditzer wrote:
> > What do you mean by "it"? ETags are simpler to implement than the above RFC,
> > and ETags are also required in WebDAV.
> 
> Etags are not really much simpler than a metadata versioning sync protocol, and they are a lot less efficient.   Having to fetch the whole directory for every directory that contains a change is expensive, both for the server and the client, unless changes are infrequent.   And because the server is the sole source of truth, it's a lot more fragile.
> 
> 
> --
> Sent from Whiteout Mail - https://whiteout.io
> 
> My PGP key: https://keys.whiteout.io/mellon@fugue.com



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




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