Are there any design patterns for configuration synchronisation [closed]

Question

I was wondering if anyone knew of any design patterns, articles or other information for the problem of synchronising settings between multiple devices.

Say a web site, an iPhone app and an iPad app; with future devices coming along later.

Any information would be greatly appreciated. If you need more information, to answer properly, please say so and I can elaborate the problem.

Answer 1

You can follow this link for the Sync ML standard. This can give a you a template to extend the framework to accommodate more data and settings not already handled This - gives detail on an open source synchronization framework

Answer 2

Forgive me if the following seems too general, but I tried to keep it high level so that it falls in line with your question. I don't know if what you're looking for would be called a "design pattern" per se. It sounds like you're looking for a synchronization paradigm/system. Note, my assumption in this response is that you need to have both online and offline capability for your application (since you explicitly mentioned synchronization.) If I'm mistaken, please let me know.

In particular, what you're probably looking for is generally implemented using two things: 1) a "distributed" database, (one that works offline on the client applications such as the mobile apps, as well as on any servers) and 2) a synchronization and conflict resolution mechanism.

A very good example of this is the source code management tool Git. Git has both of the aforementioned characteristics. First, it uses a database (e.g. a git project's file system) that is distributable (e.g. the project can be cloned from one developer's workstation to another and worked on independently.) Second, it has a mechanism for synchronization and conflict resolution mechanism. That is to say, if I attempt to synchronize (e.g. pull changes) from a colleague's workstation, differences between her code and my code may be merged (either automatically or by hand.)

Another example, and perhaps more relevant to your application, is Evernote. If I'm not mistaken, Evernote uses the same sort of paradigm (a flat file database) to synchronize documents, and has desktop clients, a web site, and mobile clients.

This is not to say that you need to use a flat file database. You could just as easily use a a relational or other database. Also, depending on what kind of data you're trying to store and synchronize, you might be able to get away with very simple conflict resolution. (For instance, if you're just storing status updates, vote counts, etc, perhaps you just choose the newest entry in the database.)

In a nutshell, the tools I've mentioned seem to follow this kind of workflow:

1. When starting a session on the client application, synchronize or "update" the client by going online and pulling new data. This is where you identify and resolve conflicts between the data on the client and what is on the server or "cloud".
2. Edit or create data "offline" on the client, be it the website, mobile app, etc.
3. Synchronize or "update" the cloud by going online and pushing the data you changed