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

Markus Unterwaditzer <markus@unterwaditzer.net> Sun, 06 December 2015 21:55 UTC

Return-Path: <markus@unterwaditzer.net>
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 5DF3C1B33F6 for <storagesync@ietfa.amsl.com>; Sun, 6 Dec 2015 13:55:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.25
X-Spam-Level:
X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] 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 LJls4Q2da5qy for <storagesync@ietfa.amsl.com>; Sun, 6 Dec 2015 13:55:04 -0800 (PST)
Received: from draco.uberspace.de (draco.uberspace.de [95.143.172.133]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 089EA1B33F5 for <storagesync@ietf.org>; Sun, 6 Dec 2015 13:55:03 -0800 (PST)
Received: (qmail 31489 invoked from network); 6 Dec 2015 21:55:00 -0000
Received: from localhost (HELO localhost) (127.0.0.1) by draco.uberspace.de with SMTP; 6 Dec 2015 21:55:00 -0000
Date: Sun, 06 Dec 2015 22:54:58 +0100
From: Markus Unterwaditzer <markus@unterwaditzer.net>
To: Ted Lemon <mellon@fugue.com>
Message-ID: <20151206215458.GA6619@localhost.localdomain>
References: <CAPpPfeDPHGR+vn0=ji9frF2kr+J=YR76g0e7yOndKzz97bxdHQ@mail.gmail.com> <566014EA.2010705@tuxed.net> <CAO_Yprbc9LMc3TmpkKpmN9hUzAix13nfuSRS5Z8jPf6xu8xjNg@mail.gmail.com> <56601F18.8030409@tuxed.net> <CAO_YpraF1UrV49Po9PZx6ZoSbcLm5gRPEKXAdTT3VvPPPWEAfg@mail.gmail.com> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <20151204181110.GA2418@localhost.localdomain> <2015120612140798437464@bjtu.edu.cn> <20151206173936.GB6290@localhost.localdomain> <1449426414825-9cdbb6fe-86b1149f-71354c71@fugue.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv"
Content-Disposition: inline
In-Reply-To: <1449426414825-9cdbb6fe-86b1149f-71354c71@fugue.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/storagesync/dfRI7qqQbxFj-GhheFjmN7V-2xo>
Cc: 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: Sun, 06 Dec 2015 21:55:06 -0000

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