Just last week I released a new draft version of BITSY that dramatically reduced its scope to provide simple primitives that can be used with different formats and protocols.
That this continues to raise the basic question - how's it different from everything out there - is an interesting problem in and of itself. This question has been asked several times on the public-webapps ML (Maciej Stachowiak, Kris Zyp, Mike Smith, Jonas Sicking, and Anne van Kesteren) in a few different contexts. So I am trying to summarize the answers here for future reference.
Contrasting with ApplicationCache in HTML5
The HTML5 ApplicationCache is one specific use case of providing a durable, read-only offline store of HTTP resources inside the browser. The browser is itself a client of the offline cache and uses a specialized protocol to perform caching of application resources such as JPG, HTML, CSS, and JS files.
A special file format is used to convey the required resources and a special versioning scheme is used to move from one version of files to another in an atomic manner. That way you wouldn't have an old JS file and a new HTML page. It is critical for browsers to have this atomicity, but that is not necessarily the case with other applications running inside browsers. Their needs are more dynamic and their behavior in failure scenarios is more flexible than a browser's internal offline store.
- ApplicationCache does not allow programmatic inclusion of items (dynamic entries were removed some time ago); all data capture in BITSY is through an API, i.e., as a dynamic entry
- ApplicationCache does not secure one user's private resources from another; BITSY requires the presence of a specified cookie
- ApplicationCache only responds to GET and HEAD requests; BITSY can respond to arbitrary HTTP requests
- ApplicationCache uses its own data format for identifying items for local storage and exludes any other formats such as JSON and Atom; BITSY does not have any format limitations
- ApplicationCache operates per its own refresh protocol and that excludes a different protocol, especially one that does not require all or nothing semantics for data versioning; BITSY has no protocol limitations.
Contrasting with Gears LocalServer
Gears is quite close to BITSY's primitives in terms of dynamic entries and capturing locally generated data. However, it is primarily a means of serving read-only requests for applications.
- LocalServer only responds to GET and HEAD requests; BITSY can respond to arbitrary HTTP requests locally
Contrasting with Dojo's Offline Toolkit OfflineRestStore
For one, you will need to cede all data access logic to the library, in this case Dojo, in order to use offline serving. This would be true of any other library. However data is not always used in this way. Your HTTP caching choice should be independent of your data access library.
- Dojo offline API provides a means of logging pending network requests and accessing data through a special API (that is different from page navigation, XHR, or other kinds of network requests originating in a browser); BITSY does not require any special API for data access because it is present in every HTTP access path.
- Requests are queued for immediate delivery to the server, even if connectivity is available. This means that your normal path is always local, even if you didn't want to. BITSY's review policy means that the normal path is not affected when browser is connected.
- Dojo switches between the network and local store based on the
navigator.onLineproperty; BITSY can use any intelligence available about battery power, connection latency and bandwidth, location, and so on to decide whether to perform a network operation or satisfy a request locally. Heck, it can even pin the app request to the local store to get maximum responsiveness.
- When using the OfflineRest Dojo API, an application cannot emulate the server. Using BITSY's interceptors, a complete server can be emulated inside the browser.
- Dojo cannot store non-textual data such as images or video; BITSY allows capture of arbitrary server-hosted resources
- OfflineRest can replay PUT, POST, and DELETE requests, provided they all do the thing Persevere understands. If you wanted to use a different semantic or if you need to use extended HTTP methods, you are out of luck.
- Dojo's synchronization protocol is internal to its OfflineRest implementation. That makes it hard to resolve conflicts or adapt to your server's requirements. With BITSY, there are no limitations on how to synchronize. It might be a little daunting, but it means any library developer can take advantage and build a suitable sync library.