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
