[aerogear-dev] Use of Differential Synchronization for data sync

[Daniel Bevenius]

>Has someone already looked at techniques that involve the client asking
for which documents (satisfying some criteria defined by the subscription)
>have changed since the time the client last connected, and then as needed
having the client ask for the latest version of some/all of those documents
>(or parts of those documents)?
Not that I'm aware of, at least I have not.

The need for a client to ask for which document have changed did not really
come up with the current demo using DS. The way this demo works is that
there are multiple clients that edit a document identified with an
documentId. The first client that connects adds the document, the following
new clients will get the latest version that is on the server. For client
that are reconnecting after being offline they will get patched with the
edits to bring it up to date. Regarding how efficient this is that is
probably is not :) The goals is mainly to try things out and see if would
work out in real life.




On 6 August 2014 16:47, Randall Hauch <rhauch at redhat.com> wrote:

>
> On Aug 6, 2014, at 1:27 AM, Daniel Bevenius <daniel.bevenius at gmail.com>
> wrote:
>
> On 6 August 2014 00:34, Jay Balunas <jbalunas at redhat.com> wrote:
>
>>
>> I actually this this a very good point (as have other points on both
>> sides).  We will rely on people like you Randall to assist us in
>> understanding the impact and advocate for the deeper server-side needs.
>>  While at the same time the client side APIs and developer experience will
>> also need to be reviewed and taken into consideration.
>>
>> I think it is important to remember that all of these are POC's and I
>> think with a problem domain as complex as this, before we get to actual
>> cross-project implementation we need to develop and flush out specs,
>> including all of these various points, risks, etc...  This would be across
>> data services, liveoak and aerogear and possibly others.
>>
>
> I think limiting the scope of this for now and enabling the underlying
> choice of storage/data service to be flexible will allow us to cater for
> the complex enterprise as well as a the simpler use cases which are
> important too if we want people to start using this and trying it out.
>
>
> Agree that the POCs should be focused and limited.
>
> Has someone already looked at techniques that involve the client asking
> for which documents (satisfying some criteria defined by the subscription)
> have changed since the time the client last connected, and then as needed
> having the client ask for the latest version of some/all of those documents
> (or parts of those documents)? I know that’s not ideal from the client
> perspective, but this is extremely simple for the service to do. In fact,
> doing more than this in the service gets very expensive and very
> complicated very quickly.
>
>
> _______________________________________________
> 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/20140807/85ae2d81/attachment.html