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