Do we have any scenario for detecting synchronization conflicts between client and
server?
--
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