[aerogear-dev] Data Sync Thoughts

Summers Pittman supittma at redhat.com
Tue Jan 28 12:43:21 EST 2014


On 01/28/2014 12:37 PM, Matthias Wessendorf wrote:
>
>
>
> On Tue, Jan 28, 2014 at 6:36 PM, Summers Pittman <supittma at redhat.com 
> <mailto:supittma at redhat.com>> wrote:
>
>     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.
>
>
> you are now buying the real-time ?
I still say skipping push initiated sync and going straight to real time 
isn't a great first release idea.

What I am buying now is [polling]->[push initialed]->[beefing up push 
adapters to include good mqtt and websocket]->[real time]

In my earlier real time text demo I wrote a websocket push adapter so 
there exists code to help with that hump.

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


More information about the aerogear-dev mailing list