On Sep 14, 2010, at 5:02 AM, Nils Breunese <[email protected]> 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
