IETF Logo Mail Archive

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

Linhui Sun <lh.sunlinh@gmail.com> Thu, 10 December 2015 03:31 UTC

Return-Path: <lh.sunlinh@gmail.com>
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 D4AA91ACE6D for <storagesync@ietfa.amsl.com>; Wed, 9 Dec 2015 19:31:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 U1FtU-6_UAzk for <storagesync@ietfa.amsl.com>; Wed, 9 Dec 2015 19:31:49 -0800 (PST)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C72E61ACE6C for <storagesync@ietf.org>; Wed, 9 Dec 2015 19:31:48 -0800 (PST)
Received: by wmec201 with SMTP id c201so7141554wme.1 for <storagesync@ietf.org>; Wed, 09 Dec 2015 19:31:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=ZwzVQT1dwe+9G+3WLvL3qrXv1/95mgMJaZUjTx8pe7w=; b=MR/7/YP9Dq6BnLMD4sR8I8o+QsZKNo82Q8P03lYfUg5wMqJqaSGYJs15Yb5C9dJbFB EwkI6TX8B42HUeHEbthQ/7SPWV1yMY8PT0LBRLD+bu6FkVstRYZ0zQYdfswc/gYnay3c wcAX77+UzKqSN0GPSodm3rAPp1ffp3sY8iAS6bgrc+WXYXnhShy9hmln2AQR3FOtfxBL 8HYezE/1LDg7mNmSnmFSSW2r08OiM1gIJUHBalCvLfHr7AAYGjcLgpvRIj+/8bHttq9T UPBcVIRVhbxk8q6J3f8T3w4Jw+aAAY9ONssH8RsWG4BFehzcau3vMYOZQyfIgUQrE+iM 0t6Q==
X-Received: by 10.28.141.140 with SMTP id p134mr39193526wmd.6.1449718307353; Wed, 09 Dec 2015 19:31:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.27.147 with HTTP; Wed, 9 Dec 2015 19:31:27 -0800 (PST)
In-Reply-To: <1449698909826-ee50bf82-5c16ad1d-d704bcec@fugue.com>
References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com, > <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <CAO_Yprbct8wFbS1WFnZZENSp-OruRUk2nRyBv4tNeKv9_CGuCg@mail.gmail.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <CAO_YprZjqs_OFC3RybVvJ4GHWb3spKMMkkFTZO=YDustp825iw@mail.gmail.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> <AE0CE9F1-3968-4229-925B-75AA37EDC327@unterwaditzer.net> <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> <506D291C-4F0B-40F3-8848-97DAAF41CAAE@cern.ch> <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com> <1449672190209-97dbcf5a-4802eeae-a6a33a55@fugue.com> <BD79DC4A-1803-49FF-A779-30844167C0DF@cern.ch> <1449698909826-ee50bf82-5c16ad1d-d704bcec@fugue.com>
From: Linhui Sun <lh.sunlinh@gmail.com>
Date: Thu, 10 Dec 2015 11:31:27 +0800
Message-ID: <CAO_Yprb7ATpPEmi0aY9mL0XtZW8PFWG_8UFmGz_9BDrfzS+5Mg@mail.gmail.com>
To: storagesync <storagesync@ietf.org>
Content-Type: multipart/alternative; boundary="001a1146a0b0bbf928052682d8af"
Archived-At: <http://mailarchive.ietf.org/arch/msg/storagesync/SiChU-l5ap9JvMETNAsxpj9ZeRg>
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, 10 Dec 2015 03:31:54 -0000

Hi,

>From the previous messages, I think we all agree that the conflict
resolution should be another layer's problem, whether to enable an
automatic merging might be a research problem or a further use case. But I
think the problem belongs to this list is whether we need to detect more on
the conflicts (not resolving them). Just knowing there are conflicts OR
knowing what are those conflicts, when and where do they come from (e.g.
the sequence of different conflict versions). Personally I prefer the
latter. Just imagine when we reconnect our device and see multiple conflict
versions but don't know anything about that. How to handle them? Which one
should we begin with?

IMHO, this is a discussion on which is enough, etag or metadata? Conflict
detection is just one of the related use cases.

Regards,
Linhui

2015-12-10 6:08 GMT+08:00 Ted Lemon <mellon@fugue.com>:

> Wednesday, Dec 9, 2015 4:25 PM Jakub Moscicki wrote:
> > But I would also tend to disagree with your statement that most of files
> are text files — as was explained by Marc Blanchet — in general it is not
> the case, not only for CERN.
>
> I think you and Marc misunderstood what I mean by "text files," but that's
> immaterial.   Whether merges can be accomplished automatically or not,
> knowing that a conflict has occurred, and when, and why, is (IMHO)
> important.
>
>
> --
> 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
>
>

v2.23.0 | Report a Bug | By Email