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
