8:35 a.m.
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/6de2250fca9150110ec03eee2af...
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(a)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-cont...
>
> 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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev