10:13 a.m.
On Wed, Dec 11, 2013 at 4:33 PM, Lucas Holmquist <lholmqui(a)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(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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev