oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [oslc-core] Choice for Configuration context request headder (was: [oslc-core] Agenda for 15 May 2014)
- From: John Arwe <johnarwe@us.ibm.com>
- To: oslc-core@lists.oasis-open.org
- Date: Wed, 11 Jun 2014 10:31:00 -0400
I was exploring your statement in [1] that
using Link headers has a negative effect on cacheability versus a new specific
header, because Vary's "units" are header names, not the more
granular "header-name=Link + link-relation-name=config-context"
test that we'd prefer in a perfect world.
Today, the usage of Link headers on
*requests* is rare, so (today) if effectively the only usage of Link request-headers
is for configuration context, the lack of granularity in the Vary units
has no practical negative effect. It introduces no new problems (today).
The rest was a thought exercise to poke
at what would happen if "today"'s assumptions were suddenly invalidated
- if a new unrelated usage for Link request headers came about in widespread
usage tomorrow, a usage that on its own did not affect cacheability. In
that case, would the config-context usage (and consequent Vary restrictions
on cacheability) create or compound any problems? Remember that what
caches do, in effect, is pattern-match incoming requests against earlier
ones, and (if a match is found and cache controls allow it, etc.) use the
cached response. So if the pattern involves all Link headers (as
it would whenever the resource requires a config context), does that cast
too wide a net?
To take a concrete artificial example,
let's say someone else decides that supplying Link rel="tag"
[HTML5] and a target that varies for each request (like I said, artificial
- this variance makes it worst case for caching). If you prefer something
incrementally more reasonable, use rel=client's request time or =client's
request log entry (nothing in [2] forces Link target IRIs to be dereferencable,
FYI - could be URNs etc).
What seems to be true is that, in the
case of a config-context-qualified resource, whose responses will always
include a Vary: Link header, effectively become uncacheable (because the
Link rel=tag content is different for each request). That risk, since
it's degree of remoteness is a matter of opinion, might concern people
enough to lean toward your "new header" alternative which lacks
this downside but otherwise functions similarly (Link's syntax allows for
the conveyance of target attributes ... attributes describing the resource
identified by the target IRI ... that I don't think your proposal allows
for, but if you don't need them "so what/that's a feechur". The
question might reduce to whether or not your alternative should allow for
extensions in its BNF - we haven't really gotten to that level of detail
in yours.)
[1] https://lists.oasis-open.org/archives/oslc-core/201405/msg00024.html
Best Regards, John
Voice US 845-435-9470 BluePages
Cloud and Smarter Infrastructure OSLC
Lead
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]