VUG5 IMS presentation

[Geoff Simmons]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 3/23/12 4:11 PM, sky at crucially.net wrote:
> Only if people change the cache-control. Expires could be turned 
> into a uint64 and safely updated, though expires is generally
> frowned upon.

To be sure I understand your argument, are you saying that in the
"almost-always" case, headers from the 304 response do not in fact
change anything about the refreshed object, so we could continue using
it without any of the copying or refcounting? Or that some information
about the object could be safely updated, despite the general rule
that objects in cache are never modified? The quotation above sounds
something like the latter, but if I read you right: convert Expires to
a uint64, which can be updated in the cached object, and convert it
back to text form on delivery.

It seems worthwhile to check for the case where the 304 response
doesn't change anything -- then we could continue to use the old
object, update its TTL etc., and discard the new object created from
the beresp.

But I'd be cautious about anything that involves updating the old
object, and that's the general answer to your question -- we don't
want to break the rule that objects in cache are not modified.

Your questions about this make sense, on first blush you wouldn't
expect validating requests to get involved in things like storage and
stevedores. If the common case can avoid that, I'm all for it,
although we'd still need the capability for the unusual case, since
304 responses could contain any headers at all.

But we can't do this in a way that breaks the concurrency model, that
would cause disruptions that would be far worse and certainly not
worth it.


Best,
Geoff
- -- 
UPLEX Systemoptimierung
Schwanenwik 24
22087 Hamburg
http://uplex.de/
Mob: +49-176-63690917
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJPcCmSAAoJEOUwvh9pJNURlScP/3hNxrkjSjP5jwgRPxlXKVOb
Ro9lL2TMfX2qHcKGVLzvB/0uBqZgW9Iy4jqUydZRZlMdUXEMsVWfQQyBx7I1xy0t
e9UcAveFyeXcsGkXfVcTDDTi09CrCDbbxanhpm4kaGTY3jjjqNh5EfQByYwwI8D7
MzdiKJ0k5tZtRlIjbhAkJ8XfDZkUhJzXA7ypV6tHnB8/jDv3K8Fj+ihTsIbGrAh+
PpSR5vpt9wi2b8S5Ujz/0BvZEW7pW+OpF0BXs4e8/dSIqEu1OOSwl7AnN964qjKf
qK4UOSCNCZRJ8qGfn/PuGO8YnRBXtoXqbtGU1h2Kjhnk7sEUCQ5Ys3b1ytV0ckId
WMKH8pT+fq1/08FNnQBj8VQyLAcfsqnFj38q/3h9wzUMx+V0b60eUXhRazv0yXOZ
hAhEUR/CvxXaHoK3gBnbdR4FC0BHU5Ut8oUeYtpxbonjePVQINa34Ck2Sljxm3ay
J0hECr5g2new59e3QT0H66dKG9RkBUkJPsASpi3weGMtPpMSDSFxLNJZ0sYD231C
PfsdoCLQ4/qI9tOKSqXXSD/eBwkrW1awrA3ROfeeSIn8QUXYftUywfzamShYMpVw
qBtKyVxFXw3Ey1ylE9mgd0QCWQloFvsbcPa8Z03Rwboo0SawKvpEjNv5uVizNqR8
uxzbZPO61RIuq5X5dxcj
=6Dto
-----END PGP SIGNATURE-----