IETF Logo Mail Archive

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

Markus Unterwaditzer <markus@unterwaditzer.net> Sun, 06 December 2015 17:39 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 12F941A8714 for <storagesync@ietfa.amsl.com>; Sun, 6 Dec 2015 09:39:42 -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 EHjiBVh8KizC for <storagesync@ietfa.amsl.com>; Sun, 6 Dec 2015 09:39:40 -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 181681A870C for <storagesync@ietf.org>; Sun, 6 Dec 2015 09:39:39 -0800 (PST)
Received: (qmail 24521 invoked from network); 6 Dec 2015 17:39:38 -0000
Received: from localhost (HELO localhost) (127.0.0.1) by draco.uberspace.de with SMTP; 6 Dec 2015 17:39:38 -0000
Date: Sun, 06 Dec 2015 18:39:36 +0100
From: Markus Unterwaditzer <markus@unterwaditzer.net>
To: Fei Song <fsong@bjtu.edu.cn>
Message-ID: <20151206173936.GB6290@localhost.localdomain>
References: <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2015120612140798437464@bjtu.edu.cn>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/storagesync/cQl4XbwC3210tbZarREDwnjYlKc>
Cc: storagesync <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 17:39:42 -0000

On Sun, Dec 06, 2015 at 12:14:08PM +0800, Fei Song wrote:
> Hi,
> 
> 
> --------------
> Fei Song
> >On Thu, Dec 03, 2015 at 02:38:05PM +0000, Ted Lemon wrote:
> >> Thursday, Dec 3, 2015 6:00 AM Linhui Sun wrote:
> >> > However I'd prefer HTTP rather than WebDAV. Since I still think WebDAV is
> >> > not suitable for today's sync service. The frequency of operations is far
> >> > higher than what WebDAV expects. For example, frequently sending propfind
> >> > to detect changes is not a good way in my view.
> >> 
> >> WebDAV is HTTP.   However, your point about propfind is correct--that doesn't
> >> scale.   What you want is a separate layer for dealing with synchronization
> >> of metadata.   You could use HTTP transport to do this, but not propfind.
> >
> >We do have that separate layer in the form of
> >https://www.ietf.org/rfc/rfc6578.txt and so far only a handful of FOSS servers
> >have implemented it. The fully-interopable way to synchronize servers still
> >includes a fallback to a full PROPFIND.
> >
> >ETags on folder listings are arguably simpler to implement than a partial
> >transaction history. remoteStorage requires those, and consequently all servers
> >must implement it.
> 
> ah, do you think it will trigger much extra burdens for the servers?

What do you mean by "it"? ETags are simpler to implement than the above RFC,
and ETags are also required in WebDAV.

- WebDAV: Etags AND a sync protocol
- remoteStorage: just etags

The latter is simpler, although you'll have to fetch the full folder listing
for each sync when something in that folder changed.

> 
> >
> >> 
> >> 
> >> --
> >> 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

v2.23.0 | Report a Bug | By Email