[aerogear-dev] Data Sync Thoughts
Summers Pittman
supittma at redhat.com
Tue Jan 28 13:01:51 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
I think we are saying the same thing. The only difference is you think
push is an optional feature for our first release and I think it isn't.
I think polling is allowable and simple but it shouldn't be the only
option in the first release.
Did I miss interpret something?
>
>
> 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/531ed87d/attachment-0001.html
More information about the aerogear-dev
mailing list