Offline web application

Question

I’m thinking about building an offline-enabled web application.

The architecture I’m considering is as follows:
Web server (remote) <--> Web server/cache (local) <--> Browser/Prism

The advantages I envision for this model are:

• Deployment is web-based, with all the advantages of this approach
• Offline-enabled
• UI (html/js) synchronization is a non-issue
• Data synchronization can be mostly automated
  • as long as I stay within a RESTful paradigm
  • I can break this as required but manual synchronization would largely remain surgical
• The local web server is started as a service; I can run arbitrary code, including behind-the-scene data synchronization
• I have complete control of the data (location, no size limit, no possibility of user deleting unknowingly)
• Prism with an extension could allow to keep the javascript closed source

Any thoughts on this architecture? Why should I / shouldn’t I use it? I'm particularly looking for success/horror stories.

The long version

Notes:

• Users are not very computer-literate. For instance, even superficially explaining how Gears works is totally out of the question.
• I WILL be held liable if data is loss, even if it’s really the users fault (short of him deleting random directories on his machine)
• I can require users to install something on their machine. It doesn’t have to be 100% web-based and/or run in a sandbox

The common solutions to this problem don’t feel adequate somehow. Here is a short analysis of each. Gears/HTML5:

• no control over data, can be deleted by users without any warning
• no control over location of data (not uniform across browsers and platforms)
• users need to open application in browser for synchronization to happen; no automatic, behind-the-scene synchronization
• different browsers are treated differently, no uniform view of data on a single machine
• limited disk space available
• synchronization is completely manual, sql-based storage makes this a pain (would be less complicated if sql tables were completely replicated but it’s not so in my case). This is a very complex problem.
• my code would be almost completely open sourced (html/js)

Adobe AIR:

• some of the above
• no server-side includes (!)
• can run in the background, but not windowless
• manual synchronization
• web caching seems complicated
• feels like a kludge somehow, I’ve had trouble installing on some machines

My requirements are:

• Web-based (must). For a number of reasons, sharing data between users for instance.
• Offline (must). The application must be fully usable offline (w/ some rare exceptions).
• Quick development (must). I’m a single developer going against players with far more business resources.
• Closed source (nice to have). Yes, I understand the open source model. However, at this point I don’t want competitors to copy me too easily. Again, they have more resources so they could take my hard work and make it better in less time than I could myself. Obviously, they can still copy me developing their own code -- that is fine.

Answer 1

Horror stories from a CRM product:

• If your application is heavily used, storing a complete copy of its data on a user's machine is unfeasible.
• If your application features data that can be updated by many users, replication is not simple. If three users with local changes synch, who wins?
• In reality, this isn't really what users want. They want real-time access to the most current data from anywhere. We had better luck offering a mobile interface to a single source of truth.

Answer 2

The only way to do this reliably is to offer some sort of "check out and lock" at the record level. When a user is going remote they must check out the records they want to work with. This check out copied the data to a local DB and prevents the record in the central DB from being modified while the record is checked out.

When the roaming user reconnects and check their locked records back in the data is updated on the central DB and unlocked.

Answer 3

The part about running the local Web server as a service appears unwise. Besides the fact that you are tied to certain operating environments that are available in the client, you are also imposing an additional burden of managing the server, on the end user. Additionally, the local Web server itself cannot be deployed in a Web-based model.

All in all, I am not too thrilled by the prospect of a real "local Web server". There is a certain bias to it, no doubt since I have proposed embedded Web servers that run inside a Web browser as part of my proposal for seamless off-line Web storage. See BITSY 0.5.0 (http://www.oracle.com/technology/tech/feeds/spec/bitsy.html)

I wonder how essential your requirement to prevent data loss at any cost is. What happens when you are offline and the disk crashes? Or there is a loss of device? In general, you want the local cache to be the least farther ahead of the server, but be prepared to tolerate loss of data to the extent that the server is behind the client. This may involve some amount of contractual negotiation or training. In practice this may not be a deal-breaker.