[aerogear-dev] Data Sync Thoughts

Matthias Wessendorf matzew at apache.org
Tue Jan 28 13:05:54 EST 2014


On Tue, Jan 28, 2014 at 6:53 PM, Summers Pittman <supittma at redhat.com>wrote:

>  On 01/28/2014 12:45 PM, Matthias Wessendorf wrote:
>
>
>
>
> On Tue, Jan 28, 2014 at 6:43 PM, Summers Pittman <supittma at redhat.com>wrote:
>
>>   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>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>wrote:
>>>
>>>>
>>>>
>>>>
>>>>  On Tue, Jan 28, 2014 at 6:26 PM, Summers Pittman <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>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
>>>>>> > wrote:
>>>>>>
>>>>>>>
>>>>>>> On Jan 28, 2014, at 10:30 AM, Summers Pittman <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]
>>
>
>  I doubt that push is (always) needed - not sure every mobile _really_
> wants to receive a notification "something is new".
>
>  If an application relies on push in order to function it is
> fundamentally broken
>
>
> Well that depends.
>

well, on iOS a user of an app can say "No" to the feature of receiving push
notifications.
If the app, using our sync bits, does NOT work when no push is available,
the api is broken.

Push, as part of the sync, should be optional, not required.

for the apple app-store guidelines it's similar: if an app only works when
it is allowed to receive push-notifications: You dont get an approval.

Push optional to wake-up: yes - but that's not really sync :) that's more a
trigger, which may cause the app connecting to our real-time service on the
sync server



> If the purpose of the application is to get updates on non critical data
> then push is a fundamental part of the apps identity.  Polling is too low
> and frequent polling is too wasteful.
>
> If the application just has to update once every few hours then polling is
> just peachy.
>
> There is no reason we can't have multiple adapters, some which need push,
> some which need real time bidirecitonal channels, and some which just need
> to get data a few times a day.  A good API can hide all of these details
> and let a dev pick/choose/implement what she needs at design 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
>>>>>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>> >
>>>>>>> > _______________________________________________
>>>>>>> > aerogear-dev mailing list
>>>>>>> > aerogear-dev at lists.jboss.org
>>>>>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> 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 listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> 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 listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> 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 listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> 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 listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> 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 listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140128/490b82be/attachment-0001.html 


More information about the aerogear-dev mailing list