Typical cappuccino apps are cached all at once with far future expires. Simply changing the URL (in an automated way) is enough to break the cache for new versions.
The caching tradeoff is there for any spriting technique, it will always be a tradeoff between reducing HTTP requests and increasing caching granularity.
Most browsers can handle two concurrent connections.
I wonder if you could create a single diff file for minor revisions. Clients would get both files in parallel as most are configured to allow two connections per host.
E.g.:
- index.html with in-line minor diff + data loader.
- data file with resource that is patched before extraction.
The right time to blow away the cache and produce a new monolithic data file would depend on your visitor profile. The nice part is that your changes could touch multiple files and still have the same overhead.
.......quick example over 10 days........
A user visits every day, 1 change per day, 1% of code modified per change:
- file re-consolidated/cached on every change, user downloads 1000%
- with diffs consolidated every 5 days, user downloads 220%
- best case conventional update, user downloads 109% (but probably a lot more)
Interesting idea. It's worth mentioning that one file in Cappuccino means one file per bundle, plus the index.html file and Objective-J.js.
A typical app has the Cappuccino bundle, and one bundle for the app code, but using an external framework means adding an additional bundle. We're exploring techniques to further concatenate bundles together (we have one in the project, but it has some negative side effects).
I'm curious about your concatenation technique. Dynamically creating multiple script objects (with document.createElement) from a data file and injecting them has been reasonably robust for me but I'm not writing a framework so I have far fewer test cases! :-)
Cappuccino has a completely custom loader and concatenated file format that creates a file system representation, such that when you do something akin to XHR("something/blah") it knows that it already downloaded it and gives it to you without a request, that way whether you ship concatenated code or not the code that fetches it is the same.
The caching tradeoff is there for any spriting technique, it will always be a tradeoff between reducing HTTP requests and increasing caching granularity.