[aerogear-dev] Data Sync Thoughts
Summers Pittman
supittma at redhat.com
Tue Jan 28 12:20:47 EST 2014
On 01/28/2014 12:17 PM, Matthias Wessendorf wrote:
>
>
>
> On Tue, Jan 28, 2014 at 6:09 PM, Summers Pittman <supittma at redhat.com
> <mailto:supittma at redhat.com>> wrote:
>
> On 01/28/2014 11:49 AM, Matthias Wessendorf wrote:
>>
>>
>>
>> On Tue, Jan 28, 2014 at 5:01 PM, Summers Pittman
>> <supittma at redhat.com <mailto:supittma at redhat.com>> wrote:
>>
>> On 01/28/2014 10:58 AM, Lucas Holmquist wrote:
>> > On Jan 28, 2014, at 10:54 AM, Summers Pittman
>> <supittma at redhat.com <mailto:supittma at redhat.com>> wrote:
>> >
>> >> On 01/28/2014 10:48 AM, Lucas Holmquist wrote:
>> >>> On Jan 28, 2014, at 10:30 AM, Summers Pittman
>> <supittma at redhat.com <mailto:supittma at redhat.com>> wrote:
>> >>>
>> >>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote:
>> >>>>> yup, this is another Data Sync thread,
>> >>>>>
>> >>>>>> From a client side perspective, i have concerns that
>> there is still not a clear direction yet.
>> >>>>> I know there are multiple ideas floating around on what
>> our model should be, i'm all for choice, but what about
>> deciding on 1 model to get started with. Then later once we
>> have this nailed down, we can have other "adapters" with
>> different models perhaps
>> >>>> All the data model is is an envelope of sync metadata
>> around an object
>> >>>> right?
>> >>> right
>> >>>
>> >>>> We also need to think about the API and server/client
>> protocol as well.
>> >>>>
>> >>>> I think that for sync 1.0 we could focus on the
>> following behavior (it
>> >>>> worked for my demos at least)
>> >>>>
>> >>>> 1. We have a Sync factory similar to Pipeline,
>> Authenticator,
>> >>>> Registrar, and KeyService.
>> >>>> 2. The Sync factory consumes/manages Synchronizer
>> instances.
>> >>>> 3. AG Synchronizer listens for sync messages using
>> UnifiedPush endpoints.
>> >>> i thought for a 1.0 we weren't thinking about "realtime"
>> >> When I hear realtime I think sub 100 ms updates to all
>> clients. (think
>> >> gaming)
>> >>
>> >> What I thought we were going for was something closer to
>> email. The
>> >> data gets changed and at some point in the future the
>> client knows. More
>> >> specifically, the thing the ONE thing that makes sync
>> special is it is a
>> >> push instead of poll implementation.
>> > this makes sense, but i guess it would be push when
>> available. thinking web and crappy web socket support( dang
>> you carriers )
>> Right. I'm not saying lets do something complicated. I'm
>> saying lets
>> use GCM, iOS CM, and simple push to send notifications to
>> tell the
>> client something. In simplePush case it is "this data
>> changed, get the
>> new stuff and update yourself". In Android and iOS case it
>> may be that
>> or it may be "here is new data".
>>
>>
>> even iOS is _very_ limited in terms of payload.
>>
>> In Android you can push entire books :-), but not w/ iOS, nor w/
>> SimplePush
> Android is still limited to 4K I think.
>
>
> Ok, not books - but a novel :-)
>
>
> I am fine with designing around the limitations of SimplePush.
>
>
> the concept of pushing a URL is more doable for iOS;
>
> However, I still prefer a 'real-time' connection type (e.g.
> websocket/sockjs/mqtt), rather than sticking the push server into this
The idea is for version 1.0 to let the server be able to 'alert' devices
that there is new data.
For 1.1 we could manage things like websockets, sockjs, mqtt, bsd
sockects, etc.
>
>>
>> In general, I am fine for getting a message saying something like
>> Documents/Schedules/1/${revision}. Then I can check my
>> revisions, fetch
>> data if necessary, update my local data, and send any
>> updates. That
>> SHOULD (I think) be doable with simplepush as well right?
>>
>> >
>> >>>> 4. AG Synchronizer sends sync messages using Pipes
>> >>>> 5. AG Synchronizer holds local data in a store
>> >>>>
>> >>>> 6. When AGSynchronizer gets a message it is responsible
>> for updating
>> >>>> the Store and then notifying code listing for updates OR
>> for notifying
>> >>>> the code that an error has occurred and needs to be
>> addressed.
>> >>>>
>> >>>> 7. When the developer updates data in the store, the
>> synchronizer
>> >>>> should package that data and send it to the server. The
>> synchronizer is
>> >>>> responsible for error handling, retrying, back-off, etc.
>> >>>>
>> >>>> 8. We should include multiple synchronizer
>> implementations to deal with
>> >>>> multiple very simple use cases which involve legacy
>> systems. (For
>> >>>> instance polling to load static data on a schedule.)
>> >>>>
>> >>>> Thoughts? Tomatoes?
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> aerogear-dev mailing list
>> >>>>> aerogear-dev at lists.jboss.org
>> <mailto:aerogear-dev at lists.jboss.org>
>> >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >>>> _______________________________________________
>> >>>> aerogear-dev mailing list
>> >>>> aerogear-dev at lists.jboss.org
>> <mailto:aerogear-dev at lists.jboss.org>
>> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >>> _______________________________________________
>> >>> aerogear-dev mailing list
>> >>> aerogear-dev at lists.jboss.org
>> <mailto:aerogear-dev at lists.jboss.org>
>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >> _______________________________________________
>> >> aerogear-dev mailing list
>> >> aerogear-dev at lists.jboss.org
>> <mailto:aerogear-dev at lists.jboss.org>
>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev at lists.jboss.org
>> <mailto:aerogear-dev at lists.jboss.org>
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> <mailto:aerogear-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140128/763498b9/attachment-0001.html
More information about the aerogear-dev
mailing list