aerogear-sync ramblings

sync.md

aerogear-sync

While I was reviewing Summers' code and ideas, I realized that I really wanted everything he did, but as a second step after we nail down the basics.

basics?

Since we've been catering the enterprise market, this essentially means we need to get the boring stuff right first, then move over to the shiny stuff, like realtime data sync, update policies & friends.

data model

For starters, I think that the most important thing that needs to be agreed upon is the data model and the atomic operations around it. As previous discussed, I really like CouchDB's datamodel -- and hate erlang ;)

{_id:<guid>, content:<arbitrary json>, rev:<last revision>}

JS

Well, it's JSON, it Just Works™

Java

I didn't want to pick on Java, but since its fame forces me to it. First stab (a courtesy of our friend Dan Bevenius):

public interface Document {
    public String id;
    public String content;
    public String rev;
}

We naturally want to kick this a notch, and use objects instead of plain strings:

public interface Document<T, ID> {
	public ID id;
	public T content;
	public String rev;
}

In this case, we can use the convention requiring that T is any object serializable to JSON. ID is a convenience shorthand since it's a GUID/UUID. I think this key isn't necessarily a natural key (a surrogate key instead).

Objective-C

;)

API levels

As soon as we have a rough data-model defined, we can start dabbling around different API levels to be served:

(parts I think are potentially deliverable for a 1.0)

• level 0: explodes when there's a conflict
• level 1: semi-automatic conflict resolution via something like google's diff-match-patch
• level 2: business rules determine who wins a conflicting update (supervisor wins over normal user)

(parts I think are potentially deliverable for a 2.0)

• level 3: real-time updates via diff-match-patch
• level 4: real-time updates via OT/EC

All those proposed API operations should be serializable, meaning I can potentially keep doing changes offline then just replying them to the server when online.

transport

Since we know about the future-looking ideas on v2.0, it would be really nice for us to specify a very simple/dumb JSON-based protocol for those change messages. Something that could accomodate both the full document updates and the OT/EC incremental bits too. I have no ideas on this, tbh.

boring usecases

scenario 1

Building inspector system - we have mobile apps that store relevant info and are bound to be accessed on places where we won't have any kind of connection, or very poor signal.

You can have several inspectors screening the same building simultaneously.

Let's say we have Agnes and Joe are doing the fire extinguisher inspection in a new hospital building. Technically each fire extinguisher has its own identifier and can be an independent document. In this case we would have no conflict happening.

Now they start finding expired fire extinguishers and start to add them to the report. This report could potentially have two divergent lists of fire extinguishers to be replenished/revalidated, as the building's compliance status.

scenario 2

Census system - we have mobile apps focused on offline data collection. We have the previous year's info that needs to be updated on the server. The interviewee needs to take a call, then asks the interviewer to come back later. This results in two sets of changes for the same document, stacked together, which should work flawlessly.

Any other ideas/comments?