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

On 9 Dec 2015, at 9:35, Ted Lemon wrote:

> Wednesday, Dec 9, 2015 9:21 AM Jakub Moscicki wrote:
>> Unless you want to dig into the type of the file and explore it’s 
>> internal structure to merge, the best you can do is to make sure a 
>> version on the server is generated for each conflict file and these 
>> may be easily accessible for manual merge by the interested users. 
>> For this etags are sufficient. From this point of view there is no 
>> difference between conflicts which are generated because two clients 
>> update the file at the same time (so conflicting uploads overlapping 
>> in time) and a case of offline client which edits locally outdated 
>> version (newer version available meanwhile on the server) and 
>> consequently uploading it when online again (so conflicting uploads 
>> not overlapping in time). In both cases it looks to me good enough if 
>> they end up as versions on the server for manual user merge/revert.
>
> Most files are text files, which are easy to merge,

I don’t agree with that statement. A lot of files nowadays  are 
complex text files in a complex format (docx, odt, …). Not easy to 
merge. Not at all. (I don’t have statistics, but my guess is that 90% 
of shared files are not plain text files)

> so yes, I do want to be able to dig into the structure of the file.   
> Even when the file isn't "easy to merge," e.g. a sound file or a 
> drawing, knowing the order of the changes can be very helpful when 
> someone is doing a manual merge.   And you can build merge tools for 
> commonly-merged files; if conflict detection is a feature of the data 
> store, then there's an incentive to build such tools, whereas if 
> everybody is accustomed to dumb data stores that don't provide this 
> feature, there's no point in making merge easy.
>
> The absence of this feature is a serious problem in my workflows; I 
> don't know if your experience is similar.   I don't really see any 
> point in inventing "yet another" storage sync mechanism that doesn't 
> provide this feature.   E.g., do you really want a calendaring system 
> that automatically re-adds files that have been deleted on one client 
> when a second client connects that hasn't seen the deletion?   An 
> address book that backs out updates?   A mail system that undeletes 
> deleted messages, or deletes messages on the client that were lost on 
> the server due to a crash?

you are giving a good example of something vastly different. Calendering 
is a very well structured and very limited dataset (compared to free 
text) that was made by design with sync considerations. The latest 
version of vcard was also designed with sync considerations, and it took 
a lot of time to get it right, (I can tell you I was the chair of 
vcarddav when we did this). And a vcard is a pretty simple dataset and 
very structured.

So I think your point just shows the inverse. Merging complex, free, not 
structured-limited-dataset files is very very difficult.

I guess your goal is great, but to me, that is for research. So if 
people want to do this work, I would split it into two working groups:
- one on the IRTF side about generic sync-merge algorithms
- one on the IETF side for the protocol components.

Marc.

>
> The use case of a small collection of large files used entirely 
> sequentially is easy to address, but (a) not very interesting and (b) 
> not actually a common use model.   It _seems_ common because we don't 
> provide anything better, and so people make do with it, but it doesn't 
> actually fit with what they are doing.   If it did, we wouldn't see 
> the proliferation of manually-labeled versions of the same file that 
> is so common in such data stores.
>
>
> --
> 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