W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

Re: I-D Action: draft-nottingham-linked-cache-inv-00.txt

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 1 Jun 2011 14:47:45 +1000
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, httpbis Group <ietf-http-wg@w3.org>, Balachander Krishnamurthy <bala@research.att.com>, cew@cs.wpi.edu
Message-Id: <47098425-91CD-4BCF-8410-D3D47A270C8E@mnot.net>
To: Brian Pane <brianp@brianp.net>

On 01/06/2011, at 2:46 PM, Brian Pane wrote:

> On Tue, May 31, 2011 at 3:05 PM, Mark Nottingham <mnot@mnot.net> wrote:
> [...]
>> I keep the associations in memory (hashed in some cases to preserve space), and that seems to work well.
> 
> Does that mean that your implementation, upon seeing a response for
> resource A that contains a Link header that invalidates resource B,
> will persistently retain the knowledge that changes to A should
> invalidate B?

Yes, until another response is received with differing information.

> I'd been assuming that the invalidation of B would be a one-time
> event: the receiving client or intermediary would invalidate B in its
> cache and forget about the message thereafter.  That's a scalable
> model (in practice, implementations limit the max total header size
> they'll allow per message, and that puts an upper bound on the number
> of invalidations that a single response message can trigger).
> Retaining the associations persistently is a much harder model to
> scale.


Remember that the association is bounded by the freshness lifetime of the response it was carried in; that keeps things reasonable.

Cheers,

--
Mark Nottingham   http://www.mnot.net/
Received on Wednesday, 1 June 2011 04:48:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:41 GMT