Re: [aerogear-dev] how about this API for sync?
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
On Dec 11, 2013, at 10:26 AM, Apostolos Emmanouilidis <aemmanou(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Attachments:
- attachment.html (text/html — 4.3 KB)