SyncManager object

[crabctrl]

Basically an extension of #2. We should have a class that handles all the gritty details of syncing, so that the actual syncing interfaces (WiFi, QR codes, whatever) doesn't have to deal with it. Note that the below is not actual valid Java syntax!

• registerProvider(provider) - Registers a provider, described below.
• genHandshake() - Generates a handshake to send to a peer. This should basically be a list of what resources are available on the local device.
• genResponse(handshake) - Generates a response based on the peer's handshake. We can use this to figure out what resources we have that our peer doesn't, and send them over.

I'm going to recommend we output a JSON object, as this is very easy for the sync interfaces to actually interact with. I'll try to figure out more about how these objects will be formatted later, still trying to figure out how we want this to work.

[crabctrl]

One way we could do it is have a Provider interface that we use for any classes that handle some type of data. It could have a methods like toJSON() and update(json) that let the SyncSession object deal with them nicely. This way we can still do fancy things, like store events in a database, instead of having one massive JSON file.

[crabctrl]

The name SyncSession is probably misleading now that I think about it, since it can actually be used across sessions... Instead let's use SyncManager or something.

[crabctrl]

Ok, a base SyncManager class and SyncProvider interface will be pushed to the sync branch momentarily. The way I've decided to do it is have SyncProviders return generic byte[] arrays as "sync objects". The SyncManager will then use this to handle syncing objects.

The handshake will contain the MD5 hashes of each sync object. The handler code will then send any objects which are not present on the system. I've decided to use generic data rather than JSON because it's easier and E F F I C I E N C Y. Note that how individual SyncProviders parse data is up to them, so we could still potentially end up using JSON at some point (although I'd like to avoid it).

[crabctrl]

I have now pushed an absolute monstrosity of a program; it's 140 lines, very dense, and has exactly 4 comments, but it should work. There are some optimizations I could make if it becomes a problem, but I don't think it should be too big of a deal, and none of my ideas would require changing the protocol so it sounds like a later problem.

Still needs to be tested.