[aerogear-dev] how about this API for sync?

[Sebastien Blanc]

On Wed, Dec 11, 2013 at 4:33 PM, Lucas Holmquist <lholmqui at redhat.com>wrote:

> wanted to dump some thoughts i was having
> Client Side Perspective
>
> let me try to dump some of the client side thoughts i have, which will
> probably be more javascript centric
>
>    -
>
>    i see data sync as keeping DataManager stores in sync with the server
>    side
>    -
>
>    not sure if it makes sense without it?
>    -
>
>    I can see using Notifier using sockJS connecting to a netty server(?)
>    to do the "real-time" updates
>    -
>
>    Sync should be plugable, so an existing REST application using
>    DataManager can just add it in or turn it off easily
>    -
>
>    the sync should have some events that the user can "listen" for, to
>    deal with conflict/changes and such
>    -
>
>    there is another type of sync that i'm also thinking off.
>
>    Since Pipeline and Datamanager are not tied to each other, do we want
>    to think about the possiblity of "syncing" them. that is when i do a read
>    currently on a pipe, i have to manually store the data, should that be
>    automatic, this used to happen in the way begining of pipeline, but we
>    removed it since we wanted to keep it modular
>
> Yes, I think that makes totally sense. If you it should be automatic,
well, we could configure it to be or not.  In the same spirit, I was
thinking of some kind of  storeFallback option we can pass to a pipe. If we
call a read on a pipe and there is no connection, we fallback automatically
on the local store to retrieve the data (with some metadata/flag saying
it's local data).

>
>
> On Dec 11, 2013, at 10:26 AM, Apostolos Emmanouilidis <aemmanou at redhat.com>
> wrote:
>
> apologies, just a correction. The security concern is that the database
> might contain data which should be NOT visible/accessible to all the
> clients.
>
> On Wed, 2013-12-11 at 16:22 +0100, Apostolos Emmanouilidis wrote:
>
> +1 for starting with an implementation similar to CouchDB. This looks
> like the Offline Lock pattern where there are version stamps and a
> client cannot fulfill a transaction if he has an old current version
> stamp.
>
> Regarding the concepts that Summers sent
> https://neil.fraser.name/writing/sync/ I feel that are some Open Source
> implementations of these concepts out there.
> e.g google-diff-match-patch[1]
>
> And something more, there is a security parameter in the data sync
> concept. The database might contain data which should be
> visible/accessible to all the clients.
>
> [1]: https://code.google.com/p/google-diff-match-patch/
>
>
> On Wed, 2013-12-11 at 10:37 +0100, Daniel Bevenius wrote:
>
>
> This conflict would the have to be handled by the client. Could we
> start out with something similar and as simple as this and evolve it?
>
>
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131211/85c5eafc/attachment-0001.html