-
Notifications
You must be signed in to change notification settings - Fork 298
FAQ
A: Right now (18 Dec 2011) it compiles to about 150k bytes of optimized ARM7 code. And the source code is about 4000 lines of Objective-C (plus another ~2500 lines from some existing utility libraries.)
By comparison, Couchbase Mobile 2.0 is about 3.5MB of code.
A: Right now (18 Dec 2011) it takes about 100ms to initialize the library and open a small database. That’s a cold launch; if the app has been launched and quit recently, leaving stuff in cache, it’s more like 60ms. This is on an iPad 2; older devices will be a bit slower.
By comparison, Couchbase Mobile 2.0 takes about 5 seconds to initialize on the same hardware.
A: I don’t know yet; I haven’t done any real benchmarks or stress-testing, nor have I put much work into optimization. With small databases, everything is pretty much instant. The most complex thing I’ve run is pulling a database of about 3,000 revisions from either a local server or from IrisCouch; this seems to go about the same speed as CouchDB.
I’m sure that it will not scale as well as CouchDB to large data sets. But I also think it’s unlikely that mobile apps are going to need to work with millions of documents.
A: There aren’t any hard limits in TouchDB itself, nor to my knowledge in SQLite. The most likely practical limit is the available disk/flash storage on the device, and of course app responsiveness as query times increase (see above).
I’ve heard that Android has a 2GB file size limit; but this should be less of a problem for TouchDB than CouchDB, because the database file doesn’t grow as fast (it doesn’t need explicit compaction) and because we’re not going to store attachments in the database file.
A: It depends on what you mean by “compatible” :)
A: Yes, its replication protocol will be entirely compatible. That’s a very important goal. Apps using TouchDB will be able to sync with servers running Apache CouchDB or BigCouch or Couchbase Server, and with hosting services like Cloudant and IrisCouch.
(I’m using the future tense because, as of 18 Dec. 2011, not everything required for 100% compatibility has been implemented yet. Attachments and filtered replication are still TBD. And it hasn’t been tested with any particularly large or complex databases. But replication does work to and from CouchDB and IrisCouch.)
A: Yes, the fundamental data model is also compatible. That’s pretty much required for replication compatibility, anyway.
(As of 18 Dec. 2011, attachments aren’t supported yet. But they will be soon.)
At this point I don’t plan on supporting design documents, or list and show functions. They don’t make a lot of sense for mobile apps. (TouchDB does support map and validation functions, and will support reduce and filters, but they’re not stored in the database, because they’re native function pointers not JavaScript code.)
A: Yes. Revision trees are implemented, and preserved across replication, though I haven’t yet implemented all the APIs needed for apps to detect and resolve conflicts.
A: Sort of. The intention is that the primary API developers will use is a native one, to match their development language. The details of this haven’t been worked out yet — the classes in the implementation are probably going to remain internal private API, with the public API on iOS being CouchCocoa, either in its current form or rewritten to call TouchDB directly.
That being said, the REST API is supported, in a limited way. The iOS implementation registers a custom URL protocol handler with the CFNetwork framework, which means that when the app uses the Cocoa NSURLConnection API to access “touchdb:” URLs, it talks to the TouchDB library in-process instead of to the network. There are no actual sockets involved at all. This makes it very easy to use existing code (such as CouchCocoa) with little or no change.
A: First off, the REST API is in-process only. TouchDB isn’t a server and can’t receive requests from any other process or host … and that’s desirable default behavior for a mobile app, anyway.
TouchDB doesn’t currently support every detail of the CouchDB REST API. We’ll add support for things that turn out to be important to mobile apps, and will probably ignore things that aren’t (like /restart and /config.)
Other things that aren’t compatible: The database file format. Configuration options (no .ini files.) Functions in interpreted languages (JS or Erlang).
A: CouchApps running in PhoneGap are definitely an interesting mobile platform. TouchDB won’t directly support these the way Couchbase Mobile 2.0 does, but I think it could be extended to without too much trouble. Mostly someone would need to implement the missing design-document support, including a JavaScript interpreter.
A: I did, but it doesn’t seem possible to optimize CouchDB’s size and startup time enough for mobile apps. We were able to get some significant improvements in Couchbase Mobile 2.0, but beyond that, further shrinking and speeding-up possibilities seemed pretty minor (on the order of 5%) when what we wanted were orders of magnitude. Most of this was intrinsic in the fact that it’s implemented in an interpreted language (Erlang) whose runtime library needs to be bundled in.
A: The design is cross-platform. After considering various interpreted languages and cross-platform libraries, I decided they had too much overhead for mobile apps, or would make the implementation too awkward. So instead the goal is to have separate implementations for each platform, but share aspects like the SQL schema, class architecture and algorithms.
A: True, from that standpoint it might have been better to start with a Java implementation for Android, since more people read Java fluently than read Objective-C. In the end it came down to the fact that I (Jens) like Objective-C better than Java, and have experience developing for iOS but not Android.
I’m pretty certain that a Java/Android implementation will follow pretty soon. I have also heard interest in an ANSI C implementation.
A: No. I am honestly not very familiar with the CouchDB implementation. I don’t think it would have made sense to refer directly to the Erlang code anyway, as the way code is structured in that language (functional, highly parallelized, non-OOP) is very different from imperative OOP languages like Objective-C and Java.
And in any case, a lot of the code is of necessity very different because it’s using SQL for storage, rather than a custom append-only B-tree implementation.
A: No, it lets SQLite take care of file storage and indexing. TouchDB database files are regular SQLite databases. There’s documentation on the schema, if you’re curious.
A: Because it’s a lot smaller, starts up a lot more quickly, and is easily embeddable into an app. Those are important factors for mobile app developers (and some desktop app developers too.) If you’re working on server-side software they probably don’t matter to you, or at least don’t outweigh the drawbacks.
A: Because CouchDB is much more mature, scales better, interoperates easily with other server processes using a REST API, and runs on more platforms.
A: Basically for the same reasons that are already outlined in the Couchbase Mobile marketing materials. The primary one is world-class, highly-flexible data sync capabilities that go way beyond what you can get from iCloud. Another factor is that the CouchCocoa API is (we think) simpler and easier to use than CoreData’s.
A: As with the previous comparison to CoreData: the big reason is sync. If your users want to work with their data on multiple devices or platforms (including the Web), or have it transparently backed up, the replication capabilities in TouchDB and CouchDB will make it very easy compared to the pain of implementing sync yourself, or trying to duct-tape your custom SQLite database to the iCloud APIs.