On Sep 8, 2014, at 4:04 AM, Daniel Bevenius <daniel.bevenius(a)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
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
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.
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!