couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Louis Gerbarg <lgerb...@gmail.com>
Subject Re: CouchDB on iPhone
Date Tue, 14 Sep 2010 22:40:40 GMT

On Sep 14, 2010, at 5:02 AM, Nils Breunese <N.Breunese@vpro.nl> wrote:

> 
> Op 14 sep 2010, om 10:13 heeft Mirko Kiefer het volgende geschreven:
> 
>> has anyone an idea on how difficult it would be to create a CouchDB installation
which could be bundled with an iOS app? Is it maybe possible to reuse some of the work done
for CouchDB on Android?
>> As Apple made quite a few changes to the App Store License Agreement I don't think
there are any legal issues anymore. The only problem might be that CouchDB allows to download
executable code in the form of design documents - so this feature shouldn't be used for iOS
apps.
> 
> Would you really call design documents 'executable code'? It's not like a design document
can do anything on the phone except things like transforming data in a database. It's all
constrained to CouchDB's behavior. Sounds more like configuration than executable code to
me.

A design document can do basically anything that a traditional database compiled function
can do, and almost certainly falls under Apple's definition of downloadable code.

> I hear the guys doing the C64 emulator app for iPhone are even putting the BASIC interpreter
back into the upcoming version.

1) That has not been approved yet (though I am hopeful).
2) The new guidelines specifically restrict downloading executable and interpreted code (which
C64 does not do and design docs do), and specifically allow code that is bundled with the
app. They say nothing about code written within the app, though I am sure that the C64 submission
will provide some more clarity on that, but it is distinctly different than CouchDB.

It should be possible to make a new JavaScript view server that actually builds a sandbox
inside an offscreen UIWebView and uses the Apple provided JavaScript interpreter, which would
get around that particular issue (and that would have been an acceptable solution before Apple's
recent changes).   

> CouchDB without design documents is pretty boring by the way.

Agreed. 

> I wonder if embedding CouchDB in an app is really the way to go. Wouldn't it be nice
to have just one CouchDB on your phone and other apps talking to that CouchDB instance? Too
bad there is no dependency management in the App Store (so CouchDB would automatically be
installed when installing your first application using CouchDB as its backend) and saying
"Please start CouchDB!" on the startup screen might not going to be accepted.

That is completely unworkable. Backgrounded apps will eventually be denied time slices (at
a maximum they will run 10 minutes before being quiesced). So you would need to get thenuser
to swap the CouchDB app to the front at least once every 10 minutes to keep it awake, which
is a pretty horrible user experience. iOS also greatly reduces the priority of background
apps since that sort of IPC is not supported, so chances are the whole thing would be pretty
lousy from a performance standpoint due to the high priority foreground process waiting on
the low priority background process. 

At this time the only way to get an acceptable user experience (absent direct support from
Apple) is to directly embedded CouchDB within the an iPhone apps address space and running
it from a thread in that app. I have been told it is possible to build the erlang vm as a
library and embedded it within another app, but I have yet to see anybody actually do that.

There are a number of other significant performance issues with trying to run CouchDB as it
currently exists. Apple's restrictions to mprotect access mean HiPE cannot run on the iPhone,
which means erlang can only be interpreted, not JITted, and the cost of all of that JSON serial
and deserialization are nontrivial. 

All of these are solvable issues, but the announced changes make almost no difference.   

Louis
Mime
View raw message