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

François Kooman <fkooman@tuxed.net> Thu, 03 December 2015 09:44 UTC

Return-Path: <fkooman@tuxed.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 22E921B2CCF for <storagesync@ietfa.amsl.com>; Thu, 3 Dec 2015 01:44:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.55
X-Spam-Level:
X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 r6HsWWZFE7Er for <storagesync@ietfa.amsl.com>; Thu, 3 Dec 2015 01:44:48 -0800 (PST)
Received: from ursa.uberspace.de (ursa.uberspace.de [95.143.172.203]) (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 69A631AD0BC for <storagesync@ietf.org>; Thu, 3 Dec 2015 01:44:47 -0800 (PST)
Received: (qmail 24619 invoked from network); 3 Dec 2015 09:44:44 -0000
Received: from localhost (HELO ?10.87.3.103?) (127.0.0.1) by ursa.uberspace.de with SMTP; 3 Dec 2015 09:44:44 -0000
To: fsong@bjtu.edu.cn, Michiel de Jong <mbdejong@mozilla.com>
References: <mailman.108.1449000023.26068.storagesync@ietf.org> <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <CAO_YprZhCmUxEf=aGCYL=+CLbjUoD1ifpDFsrS7N40Npo4wr+w@mail.gmail.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <CAPpPfeAdrCZcsYZo7=W6N14K4F2LutXN8BFTetikzKZSr8+vVA@mail.gmail.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn>
From: François Kooman <fkooman@tuxed.net>
X-Enigmail-Draft-Status: N1110
Message-ID: <56600F0A.9000200@tuxed.net>
Date: Thu, 03 Dec 2015 10:44:42 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/storagesync/O5NFzM7i7KopvkxMAGrBViEK09s>
Cc: Linhui Sun <lh.sunlinh@gmail.com>, storagesync <storagesync@ietf.org>, Hugo González Labrador <ietf@hugo.labkode.com>
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, 03 Dec 2015 09:44:50 -0000

On 12/03/2015 10:06 AM, fsong@bjtu.edu.cn wrote:
> If we really want to discuss the Pros and Cons of WebDAV, can we
> mark these three reasons as disadvantages of WebDAV? any support for
> that?

Personally, I do not think that is fair.

> 1) it's a lot of work to implement this without using an existing
> WebDAV library 

I do not see a problem in reusing an existing WebDAV library. This has
the added benefit that you get a lot of functionality 'for free' and
that existing test suites are available for testing compatibility. This
is purely a practical argument!

> 2) in practice, a lot of WebDAV servers get it wrong,
> or don't implement all of WebDAV. It's very annoying for client
> implementers to have to deal with servers that e.g. chose not to
> implement LOCK and UNLOCK. 

The point is not to have a fully compliant (whatever that is exactly)
WebDAV server. Either this ML (or remoteStorage specification) could
determine a subset of WebDAV that would be required to be implemented.
E.g. we exhaustively list the verbs that need to be implemented and
their expected behavior. If we keep this a limited as possible and stay
away from experimental features we have a high probability that most
libraries will get it right! If we stay away from locking and ACLs the
library situation looks a lot brighter :)

> 3) we don't really need all these advanced
> features on top of standard HTTP, just supporting GET/PUT/DELETE for
> resources, and adding a simple folder description format, is enough
> for most applications.

Exactly!

> For the target of our ISS group, whether the WebDAV can be reused is 
> critical.

Well, my point is that there is little reason to reinvent the wheel if
the only benefit is to use JSON instead of XML for folder listings. The
amount of experience and available tooling for WebDAV is already huge!
It would be a waste to throw this away just for liking JSON better.

But maybe there are other reasons using (a limited set of) WebDAV is
impossible or unwanted...

Cheers,
François