So, you're really looking for entry-level, time-based invalidation, no?
I guess the simplest way to do this would be to dereference the link
and see if you get a 404/410; if you do, you know it's no longer good.
That's not terribly efficient, but OTOH managing metadata in multiple
places is tricky, and predicting the future doubly so :) Most people
get expiration times really wrong. And clock sync becomes an issue as
well.
I'd think that if you have reasonable control over the polling of the
feed, and a solid enough state model (which might include an explicit
deletion mechanism), you could have a similar effect by just removing
the items from the feed when they expire, with the expectation that
when they disappear from the feed, they disappear from the client.
Would that work for your use case?
On 09/08/2005, at 9:07 PM, James M Snell wrote:
First off, let me stress that I am NOT talking about caching
scenarios here... (my use of the terms "application layer" and
"transport layer" were an unfortunate mistake on my part that only
served to confuse my point)
Let's get away from the multiprotocol question for a bit (it never
leads anywhere constructive anyway)... Let's consider an aggregator
scenario. Take an entry from a feed that is supposed to expire
after 10 days. The feed document is served up to the aggregator
with the proper HTTP headers for expiration. The entry is
extracted from the original feed and dumped into an aggregated
feed. Suppose each of the entries in the aggregated feed are
supposed to have their own distinct expirations. How should the
aggregator communicate the appropriate expirations to the
subscriber? Specifying expirations on the HTTP level does not
allow me to specify expirations for individual entries within a
feed. Use case: an online retailer wishes to produce a "special
offers" feed. Each offer in the feed is a distinct entity with
it's own terms and own expiration: e.g. some offers are valid for
a week, other offers are valid for two weeks, etc. The expiration
of the offer (a business level construct) is independent of whether
or not the feed is being cached or not (a protocol level
construct); publishing a new version of the feed (e.g. by adding a
new offer to the feed) should have no impact on the expiration of
prior offers published to the feed.
Again, I am NOT attempting to reinvent an abstract or transport-
neutral caching mechanism in the same sense that the atom:updated
element is not attempting to reinvent Last-Modified or that the via
link relation is not attempting to reinvent the Via header, etc.
They serve completely different purposes. The expires and max-age
extensions I am proposing should NOT be used for cache control of
the Atom documents in which they appear.
>I think we can declare victory here by simply a) using whatever
caching mechanism is available, and b) designating a "won't
change" flag.
Speaking *strictly* about cache control of Atom documents, +1. No
document level mechanisms for cache control are necessary.
- James
Mark Nottingham wrote:
HTTP isn't a transport protocol, it's a transfer protocol; i.e.,
the caching information (and other entity metadata) are *part of*
the entity, not something that's conceptually separate.
The problem with having an "abstract" or "transport-neutral"
concept of caching is that it leaves you with an awkward choice;
you can either a) exactly replicate the HTTP caching model, which
is difficult to do in other protocols, b) "dumb down" HTTP
caching to a subset that's "neutral", or c) introduce a
contradictory caching model and suffer the clashes between HTTP
caching and it.
This is the same road that Web services sometimes tries to go
down, and it's a painful one; coming up with the grand, protocol-
neutral abstraction that enables all of the protocol-specific
features is hard, and IMO not necessary. Ask yourself: are there
any situations where you *have* to be able to seamlessly switch
between protocols, or is it just a "convenience?"
I think we can declare victory here by simply a) using whatever
caching mechanism is available, and b) designating a "won't
change" flag.
On 09/08/2005, at 11:53 AM, James M Snell wrote:
Henry Story wrote:
Now I am wondering if the http mechanism is perhaps all that is
needed
for what I want with the unchanging archives. If it is then
perhaps this
could be explained in the Feed History RFC. Or are there other
reasons to
add and "expires" tag to the document itself?
On the application level, a feed or entry may expire or age
indepedently of whatever caching mechanisms may be applied at
the transport level. For example, imagine a source that
publishes special offers in the form of Atom entries that expire
at a given point in time. Now suppose that those entries are
being distributed via XMPP and HTTP. It is helpful to have a
transport independent expiration/max-age mechanism whose
semantics operate on the application layer rather than the
transport layer.
- James
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
