[aerogear-dev] how about this API for sync?

[Summers Pittman]

On 12/10/2013 06:48 PM, Bruno Oliveira wrote:
> +1 to include this table at our documentation https://github.com/aerogear/aerogear.org/blob/6de2250fca9150110ec03eee2af7f5418cbe44b8/docs/specs/aerogear-data-sync/index.md
>
> Do we have any scenario for detecting synchronization conflicts between client and server?
We've straw manned a few.

Least complex: The user has a set features on two devices each with 
their own settings.  These are synchronized over all of the user's 
devices.  On the first device he disables a feature (and thus all of its 
settings), but on the second device he enables settings for the feature 
he disabled on the other device.

How do these resolve and how is the resolution transmitted.

More complex:  Multiple users are editing a todo list.  Two users delete 
the first item.  How do we ensure that only one item is deleted? (Or how 
do we build our APIs and protocol so that the backend server deletes 
only one item)

Most complex: N (where N is > 2) edit the same document and create 
conflicts.  How do we enable resolving all of these and resyncing the 
original document.

Even more most complex:  The same about but with an Image / binary data/ 
etc.

>
> --
> abstractj
>
> On December 10, 2013 at 7:09:53 PM, Sebastien Blanc (scm.blanc at gmail.com) wrote:
>>   
>> Agreed, we could use Summer's table as start point and extract
>> maybe more
>> "concrete" use cases from it ?
>>   
>> https://gist.github.com/secondsun/e6552abfbf51ed915d92#file-table-of-contents-md
>>   
>> Use Case Push/PollRealtimeServer APIs UsedPeriodic Read Only
>> Update
>> PollNAny legacyPipelines,
>> Authentication, Stores Real Time Read Only UpdatePush Y(ish)Legacy
>> +
>> Updates for Unified PushUnified Push, Store Simple Settings
>> Sync
>> PushY(ish)Legacy + Updates for Unified Push + Updates for conflict
>> mgmtPipelines,
>> Authentication, UnifiedPush, Store Real Time Text SyncPush
>> YNeeds lots of
>> custom code, vert.x realtime componentUnifiedPush, Store
>>   
>>   
>> On Tue, Dec 10, 2013 at 8:45 PM, Bruno Oliveira
>> wrote:
>>   
>>> Sorry because I got lost into this thread, but do we have any use
>> case
>>> scenarios to understand which problem we are willing to solve?
>>>
>>> I think would be nice to start to enumerate at least 3 and choose
>> 1 to
>>> stay focused. Thoughts?
>>>
>>> --
>>> abstractj
>>>
>>> On December 10, 2013 at 3:59:45 PM, Summers Pittman (supittma at redhat.com)
>>> wrote:
>>>>> The difference is we have different opinions, use cases,
>> and
>>>> ideas of "correct". Our users will also have said ideas so our
>>>> solution should make it possible for both to be supported (even
>>>> if we only provide one).
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev