[aerogear-dev] Data Sync Thoughts

Tue Jan 28 12:37:26 EST 2014

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 ?

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