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

Ted Lemon <mellon@fugue.com> Sat, 05 December 2015 14:56 UTC

Return-Path: <mellon@fugue.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 7A7E91B2A87 for <storagesync@ietfa.amsl.com>; Sat, 5 Dec 2015 06:56:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level:
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 09zWN-6-JkXl for <storagesync@ietfa.amsl.com>; Sat, 5 Dec 2015 06:56:09 -0800 (PST)
Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id 333101B2A88 for <storagesync@ietf.org>; Sat, 5 Dec 2015 06:56:08 -0800 (PST)
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14493273642820.7448489863891155"
From: Ted Lemon <mellon@fugue.com>
To: lh.sunlinh@gmail.com
In-Reply-To: <CAO_YprYx4WJc2meJiXPwcUM-eSuTRgHBt5PoeLGGTSd6hxBVLg@mail.gmail.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> <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> <D51EEF1B-13C8-4BBB-91C0-1B473D17759C@cern.ch> <1449170047359-e297ed6e-b9fd94e9-570ca980@fugue.com> <CAO_YpraSokj1S5-mZ17nMiN91c+PfHtMfGSjsFZ1zopQ59eUPQ@mail.gmail.com> <1449246571559-58500bfc-f92fedd1-047d217b@fugue.com> <CAO_YprZOjDN46-kEJhmjbyokRjbPCU2KNK1xrzQiH3vQTm4w9w@mail.gmail.com> <1449294461284-b55dffbc-67521f90-03218253@fugue.com> <CAO_YprYx4WJc2meJiXPwcUM-eSuTRgHBt5PoeLGGTSd6hxBVLg@mail.gmail.com>
Date: Sat, 05 Dec 2015 14:56:04 +0000
Message-Id: <1449327364595-79ead32f-910f9aed-8ffc5256@fugue.com>
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/storagesync/nYctzh-H1LDpAgQ1a8pwCn0r24I>
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: Sat, 05 Dec 2015 14:56:10 -0000

Saturday, Dec 5, 2015 1:09 AM Linhui Sun wrote:
> It sounds like this could resolve your IMAP issue to some extent. I'm
> wondering could we understand this in another way for the practical
> application: we have a group of servers and a group of clients. Inside the
> group of servers, they use a explicit distributed peer model and any new
> info will be propagated to the group members. Between the server group and
> client group, it is simply C/S model but a client can sync to arbitrary one
> from the server group. However inside the group of clients, they have no
> communications since I don't want my client to talk to anyone else.

Any two devices that share the same server and can update it, whether they use a peer-to-peer protocol to talk to the server or a client-server protocol, are communicating.   However, if you just mean that you don't want to do the work to set up the communication, but you want to use the same protocol in all cases, then yes, this is a good example of a configuration that could work with the peer-to-peer sync model: what peer-to-peer means in this context is simply that it in principle for any two participants can communicate, not that they are configured so that they _actually_ communicate.


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mellon@fugue.com