On 01/28/2014 12:45 PM, Matthias Wessendorf wrote:



On Tue, Jan 28, 2014 at 6:43 PM, Summers Pittman <supittma@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@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@apache.org> wrote:



On Tue, Jan 28, 2014 at 6:26 PM, Summers Pittman <supittma@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@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@redhat.com> wrote:

On Jan 28, 2014, at 10:30 AM, Summers Pittman <supittma@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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev