[aerogear-dev] Data Sync Thoughts

Summers Pittman supittma at redhat.com
Tue Jan 28 12:36:07 EST 2014


On 01/28/2014 12:32 PM, Matthias Wessendorf wrote:
>
>
>
> On Tue, Jan 28, 2014 at 6:32 PM, Matthias Wessendorf 
> <matzew at apache.org <mailto:matzew at apache.org>> wrote:
>
>
>
>
>     On Tue, Jan 28, 2014 at 6:26 PM, Summers Pittman
>     <supittma at redhat.com <mailto:supittma at redhat.com>> wrote:
>
>         On 01/28/2014 12:13 PM, Matthias Wessendorf wrote:
>>
>>
>>
>>         On Tue, Jan 28, 2014 at 6:08 PM, Summers Pittman
>>         <supittma at redhat.com <mailto:supittma at redhat.com>> wrote:
>>
>>             On 01/28/2014 11:46 AM, Matthias Wessendorf wrote:
>>>
>>>
>>>
>>>             On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist
>>>             <lholmqui at redhat.com <mailto:lholmqui at redhat.com>> 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"
>>>
>>>
>>>             that is my impression as well, talking to Dan on IRC;
>>>             ATM all is polling, but the sync-server will be cable of
>>>             doing WebSocket/SockJS, so "connected" clients, can sync.
>>             Polling is MURDER on battery, performance, and "feel". 
>>             WebSockets and SockJS are awesome ideas for a future
>>             implementation for "real time".
>>
>>
>>         As far as I understood it, the sync-server just started w/
>>         polling (pure HTTP). I think that WebSocket/SockJS is not
>>         really that far away, in terms of 'future'
>>
>>
>>>
>>>             Push should be really used for 'wake-up', instead of
>>>             changing real information; Also SimplePush clients could
>>>             not even integrate here (the protocol just uses version
>>>             (or timestamps)
>>             Yes.
>>
>>             On the topic of Simple Push, you push a URL so in theory
>>             you could push
>>             /Documents/${collecitonName}/${id}/${rev_id} and have
>>             simple push setup to accept URLS formatted that way
>>             right?  Or is it more limited than that?
>>
>>
>>         you can simply ONLY push a version number, that's it
>         I just reread things.  It is worse than that.  You can
>         (should) only push an increasing version number.  So anything
>         checksum based will fail.
>
>
>
>     best practice is 'timestamp' - that's all you can push over to
>     those devices
>
>
> for a good reason
Yeah.  I keep forgetting how simple simplepush is.

My original though on simple push was that a client to register as a 
listener for /Documents/Collections and it would receive pushes to 
/Documents/Collections/foo/bar.  I was totally wrong :)

This gives a much better context to everything that is also going on.

>
>>
>>
>>
>>
>>>
>>>
>>>
>>>                 > 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
>>>
>>>
>>>
>>>
>>>             -- 
>>>             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  <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
>
>
>
>
> -- 
> 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/6b49304d/attachment-0001.html 


More information about the aerogear-dev mailing list