[aerogear-dev] Differential Synchronization: Shadow/Backup Revision Control and its Garbage Collection

[Randall Hauch]

On Sep 8, 2014, at 4:04 AM, Daniel Bevenius <daniel.bevenius at gmail.com> wrote:

> >What happens when a client on a mobile device loses its connection for a short period of time and then reconnects?
> The edits/patches/operations on the client would be stacked up and later when an connection is available that stack of edits/patches/operations would be sent to the server.

I more concerned about what happens in the server when a client on a mobile device loses its connection. Server-side session management adds complexity and reduces scalability.

> >What if load balancing cause the client to reconnect to a different process in the cluster?
> If we allow for different types of what we currently call a DataStore to be pluggable, then it would be possible for that client to reconnect to a different instance with the assumption here that the underlying datastore is distributed.  

Sure, except doesn’t that presume that the server’s client states are distributed (or distributable) or persisted? Again, this is more complexity creep.

> >BTW, please tell me if the whole purpose of AeroGear's Data Sync feature is to satisfy this and only this scenario. If so, then I apologize for being a distraction.)
> No, it is not the only scenario. We want to satisfy as many scenarios as possible, but we also have to start somewhere and preferable start small and build out from there. In the roadmap, we outlined as the first steps what is called conflict resolution. This is what our initial focus will be on and it will require minimal server side changes to existing server application (no server side state for clients). Our hope is that doing this might gain us some early adopters. This does not rule out that this could not be evolve into something like you've described in you email above, more about this later.  

Yup, the conflict resolution first step is a great approach. It’s lightweight, and I think Data Sync can do an awful lot with it. My hunch is that if a server supported it, then the client-side SDK can add a lot of the features I was talking about earlier.

>  
> > If the client goes offline and then back online, the Data Sync functionality in the SDK would figure out which of the local entities the client has changed, and request from the server the latest revisions for each of them. Data Sync then merges the local changes onto the latest revisions (perhaps asking the user to manually resolve anything that cannot be automatically resolved),  computes the new effective changes, and then sends a single batch request to the server to apply them. Some, all or none changes are accepted, and likely the application then has to decide whether to continue the process again, revert to the server’s versions, etc.  
> This sounds simliar to what we have discussed as conflict resolution in the Data Sync roadmap. It differs somewhat, like we don't specify anything with regard to batches as the goal it to limit the changes need for existing server implementations,  in that the server only detects a conflict and does not try to apply any effective changes/operations/patches but instead works with complete objects/documents.

Batches does complicate things, and they’re not needed right from the start. Using a batch instead of multiple separate requests reduces network costs, and this is always important in mobile. But it also allows the client to do control consistency and atomicity of their updates. Without batches, some apps will just be harder to write and will have to have logic that compensates for when one update request succeeded and a second did not.

>  
> >The SDK would also make use of subscriptions/notifications so that it can be told immediately when entities are changed.
> This is considered as a later part of conflict resolution where we notifications are planned to be used. 

Right. I was just trying to point out how it fits in to my scenario.

>  
> >The kinds of requests needed to support data sync in this scenario are fairly basic, so the server doesn’t have to be that complicated. Best of all, the server is not required to maintain any client-specific state.
> This does sound like what we are trying to do with the conflict resolution approach. I know that it is even more basic than what you have described here but we could extend the roadmap to include such features.  

+1.


> I think there will be use cases for both the conflict resolution and the data sync approaches and users that might be quite happy with conflict resolution. I think it would make sense to split the two roadmaps/specs into separate ones. At the moment it looks, and was the original idea, that this would involve into the "real-time" datasync solution. But have these separate would hopefully make this clear that these are independent and can evolve independently.
> Does this sound alright with everyone?

That sounds good to me. I think they do target slightly different scenarios.

Thanks for the discussion!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140908/ecfa3f34/attachment.html