[aerogear-dev] Data Sync Thoughts

[Summers Pittman]

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