Stormy - I will happily blog it and take pictures...but you don't want my notes...I was always the one in college that borrowed notes. wrote:

the way down to app developers increases the cognitive load for folks using the platform. Enabling/disabling it on a per-installation level, and - maybe - a per-space level, might be a decent compromi

Once - configurable on a per-app, per space, or per deployment basis?

For me the primary use case to developing management tools on top of the CC API, and being able to intelligently cache information about the state of those resources. Without etags or serial numbers o

I think ETags is reasonable thought as well.

I've wanted something similar as well. On a related note, having a CC API 'serial' number (for each object in CC - apps, spaces, etc) that increments on every change relevant to that object would be o

This is very very cool - just sent to the 200 SE's I'm training on CloudFoundry in Tokyo this week.

executing a command, concluding an interactive session, or copying a file into an instance, that instance will be restarted. I have to agree with Matt S here - having this as default behavior is rough

I can't speak to a), but the general pattern for b) would be to store the actual blob data into an object store of some sort (whether public like AWS S3 or Azure, etc, or on a private service like Sca