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

[Markus Unterwaditzer <[e-mail]>]

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

I think we have a misunderstanding here.

We have a server storage that has an etag for each file. We have a client
storage that has an etag for each file.

The sync client accesses those *and* a "status" file that contains a list of
all files + etags for *both* sides, as they were after the previous sync.  This
is similar to the algorithm described in
http://blog.ezyang.com/2012/08/how-offlineimap-works/, except that one doesn't
deal with files being modified. As said, this warrants a longer blogpost, but I
don't have the time to write one now.

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