[aerogear-dev] Data Sync Thoughts
Summers Pittman
supittma at redhat.com
Tue Jan 28 13:15:11 EST 2014
On 01/28/2014 01:05 PM, Matthias Wessendorf wrote:
>
>
>
> On Tue, Jan 28, 2014 at 6:53 PM, Summers Pittman <supittma at redhat.com
> <mailto: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 <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.
>
>
> 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.
Thanks for reminding me why I think iOS is a dead end platform divorced
from reality ;)
>
> 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
Sync is being able to resolve changes in remote and local data in
response to a trigger. That trigger can be time (polling every x), user
input (a ugly refresh button), push messages (a proprietary tether to a
closed source software stack), or responses to crystal telepathy
(Bluetooth accessory only compatible with iOS 9) for all I care ;) We
should make a point to nail down which ones we listen to for 1.0 and
which ones we punt.
>
> 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 <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/0c7cfa34/attachment-0001.html
More information about the aerogear-dev
mailing list