cappuccino

k" (default) and "black-translucent", both seemed to work for me, but I stuck with the default. The biggest problem is with the default image, i.e. "apple-touch-startup-image". For some insane reason it expects the PNG to be 748px wide by 1024px tall. This aspect ratio implies the image should be portrait oriented, yet the 20px for the status bar is taken from the narrower dimension, implying that it should be landscape oriented. And in fact the image is scaled from 748x1024 to 768x1004. There is no way around this AFAICT. Original default.png image: http://cl.ly/JCs Displayed in portrait orientation: http://cl.ly/IyM Displayed in landscape orientation: http://cl.ly/Ibx The only way to get something reasonable is to squash your default image in the opposite direction. That is, start with a 748x1024 image, crop it to 768x1004, then scale it back to 748x1024. Unfortunately then you end up with a white bar along one edge in landscape mode. Madness. If I'm mistaken about any of this I'd love to know.

local files, scp, rsync, svn, etc), runs an optional build command (like "ant"), copies source paths to destination paths in a deployment directory, gzips the deployment directory, scp's the code to your server(s), ungzips it, and does a little magic... Each version is placed in it's entirety in a uniquely named (unix timestamp) subdirectory. We could just redirect from "/" to "/1221268756/" (for example) but that's incredibly ugly, so we use the little known HTML <base> tag to trick it. The index.html file in "/" is identical to the one in "/1221268756/" except it has a <base> tag which tells the app all URLs are relative to "/1221268756/" instead of the default containing directory ("/"). And it actually seems to work really well. The big advantage of this is you can set your cache expire date arbitrarily far in the future, and your entire app will be cached until you change index.html to point to a new <base>. 280 Slides, which is ~2.6MB uncompressed, loads on my computer in about 1.5 seconds if it's cached. The only problem with this approach is when you deploy, all clients will have to re-download every resource, even ones that don't change. A more granular system would be ideal, but significantly more complex. I looked at Capistrano briefly but decided against it for some reason I can't remember. Perhaps that would have been better, but c'est la vie...