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

[Linhui Sun <[e-mail]>]

On 周一, 12月 7, 2015 at 09:22, Markus Unterwaditzer <[e-mail]>
wrote:
On Mon, Dec 07, 2015 at 09:09:08AM +0800, Linhui Sun wrote:
> 2015-12-07 8:54 GMT+08:00 Markus Unterwaditzer <[e-mail]>:
>
> > On Mon, Dec 07, 2015 at 08:50:00AM +0800, Linhui Sun wrote:
> > > But what if the file has been changed during two sync processes by
> > another
> > > participant who also shares the file.
> >
> > Those are sync conflicts, how to deal with then depends on the kind of
> > data you
> > deal with.
> >
> That works, but do you think this could make the things complicated? It
> sounds like different situations have different mechanisms. Why not just
> make the metadata exchanged, any disadvantage for doing that?

I don't know what that means. The question is why you just keep the metadata locally at client side but not
exchange the metadata between client and server to make both of them (both
peers) have the latest metadata store in time.

>
> >
> > >
> > > >
> > > > On Mon, Dec 07, 2015 at 08:17:26AM +0800, Linhui Sun wrote:
> > > > > On 周一, 12月 7, 2015 at 01:36, Markus Unterwaditzer <
> > [e-mail]>
> > > > > wrote:
> > > > > > IMO, etag is designed for client side cache. A typical usage: if
> > the file
> > > > > > on the server has no actual change, the client will use the cache
> > and the
> > > > > > server does not need to send the file content again. While for a
> > storage
> > > > > > service, we also need some some similar mechanism at server side.
> > In this
> > > > > > way, the client do not need to upload unchanged content to the
> > server.
> > > > >
> > > > > There is no "true-and-only" usecase for etags, and no, you do not
> > need
> > > > anything
> > > > > more than etags for synchronization. Using a additional "metadata"
> > file, the
> > > > > client can cheaply determine whether local content changed and
> > whether
> > > server
> > > > > content changed, and that's all that is required for (in this case)
> > file
> > > > > synchronization. Sync conflicts are a different story, and the
> > solution to
> > > > that
> > > > > heavily depends on the kind of data you're syncing. I'm a little bit
> > > confused
> > > > here: if I have a metadata file, why do I still need
> > > > > the etag? The metadata file should contain something equivalent to
> > the etag.
> > > > >
> > > > > >
> > > > > > > --
> > > > > > > Sent from my phone. Please excuse my brevity.
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Storagesync mailing list
> > > > > > > [e-mail]
> > > > > > > [https://www.ietf.org/mailman/listinfo/storagesync] https://www.ietf.org/mailman/listinfo/storagesync
[https://www.ietf.org/mailman/listinfo/storagesync]
> > > > > > >
> > > > >
> > > > > > _______________________________________________
> > > > > > Storagesync mailing list
> > > > > > [e-mail]
> > > > > > [https://www.ietf.org/mailman/listinfo/storagesync] https://www.ietf.org/mailman/listinfo/storagesync
[https://www.ietf.org/mailman/listinfo/storagesync]
> > > >
> > > > > _______________________________________________
> > > > > Storagesync mailing list
> > > > > [e-mail]
> > > > > [https://www.ietf.org/mailman/listinfo/storagesync] https://www.ietf.org/mailman/listinfo/storagesync
[https://www.ietf.org/mailman/listinfo/storagesync]
> >

> _______________________________________________
> Storagesync mailing list
> [e-mail]
> [https://www.ietf.org/mailman/listinfo/storagesync] https://www.ietf.org/mailman/listinfo/storagesync
[https://www.ietf.org/mailman/listinfo/storagesync]