So I'm not sure I see how the data model in the current sync spec helps
with syncing data. Also the current spec draft is lacking a transport
format as well.
I propose using the dual shadow data model described here:
## Data Model: and Transport:
Client side each piece of data which is currently in active
synchronization (ie the client is sending AND receiving updates at the
same time) has a copy of her data which represents the current assumed
good synchronized state. She also has the copy of the data she is
editing. When she has finished her edit (for an use case specific
defined by the developer definition of finish) the system will generate
a diff based on the JSON representations of her shadow and her model.
The model will replace the shadow and a diff of her data as well as a
checksum of her data will be sent to the server for processing.
Server side the server will maintain its own model of the shared data,
as well as shadows for each session currently sync the data. When it
receives a sync, the diff will be applied to the server's shadow of the
session which sent the diff. If the diff merges cleanly and the
checksum of the server shadow matches the checksum in the transport,
then the server will update the canonical model of the data against what
was in the session's updated shadow. The server will then diff all of
its sessions' shadows against its model and send out diff messages to
I've made a spreadsheet* where I follow one of QMX's sample applications
and step through a few workflows with my proposed data model. (This is
the data model I use in the DevNexus sync demo and the real time text
demo). I would welcome someone to implement the use case with QMX's
proposed data model.
wdyt? Who would mind doing the data flow for the other model?
What do you think about add Openshift profile in our backend projects?
<!-- When built in OpenShift the 'openshift' profile will be used when invoking mvn. -->
<!-- Use this profile for any OpenShift specific customization your app will need. -->
<!-- By default that is to put the resulting archive into the 'deployments' folder. -->
<!-- http://maven.apache.org/guides/mini/guide-building-for-different-environm... -->
-- Daniel Passos
I just finished a quick POC to see how hard it would be to create a simple push java client. And guess what it wasn’t hard at all only 20 / 30 lines of code. Now to make this a proper lib I was struggling a bit with how to name this thing. So I’m keeping close to the JS version as this is the same functionality. So I also have a UnifiedPushClient, that enables you to register your simple push endpoint. This would be about one class so I don’t think we would need a separate module for this. But that does make the naming of this module harder :)
I was thinking just calling it aerogear-simplepush-java so what do you think?
I was hoping to find a way to get plugged into the AeroGear project. I've looked at the AG roadmaps, talked with Jay and Steve, and I'm really excited about what you've been doing!
I wanted to see how I could get plugged in. I was thinking of working on a quickstart or two, and possibly even some blogging. To start topics like "what if" scenarios for companies to see how they could potentially use AG to extend current IT infrastructures to mobile. These are just my ideas. I'm open to your thought on what are the needs of the community and how I can help.
Happy Tuesday !
in December, I’ve reported  and today Passos asked me if I could rather send it here to discuss it, as this behavior is the same in other platform’s implementations (which I wasn’t aware of before). So please read the description on that JIRA issue. Basically I have nothing more to say about it, what’s not in the description already. So, what do you think?
1 - https://issues.jboss.org/browse/AGDROID-173