[aerogear-dev] Data Sync Thoughts

Tue Jan 28 12:45:52 EST 2014

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

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140128/28319b97/attachment-0001.html 