[aerogear-dev] Data Sync Thoughts
Summers Pittman
supittma at redhat.com
Tue Jan 28 12:53:19 EST 2014
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
> <mailto: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 <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]
>
>
> 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. 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
>>>>> <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 <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/e2f20bd5/attachment-0001.html
More information about the aerogear-dev
mailing list