My preference is that we stick with the decision we made in
the November
F2F which recognized the complexities
of invalidation caching and
deferred any
specification of such until after 1.0. Our current model
is based on a well understood and time tested
caching model.
Invalidation, though ultimately
an important developers tools for
achieving optimal
performance needs our time and energy to specify a
complete and flexible solution. Our current solution is
satisfactory.
As cache maintanence is
controlled by the consumer, consumers are free
to
provide the semantics you describe in this change control and market
themselves as a better solution without our
specification saying
anything about
invalidation. Portlets running on systems without this
feature merely receive "stale" data/content --
something that is
inherent in caching
systems/portals/consumers anyway.
Some reasons for deferring:
We
should be concerned about implementability by the consumer. Though
some consumers will deal with the complexities of
implementing
invalidation based caching, we
shouldn't require all consumers to do so.
Such
consumers, however, will likely find it easy/convenient to
implement our current caching semantics. Ultimately, work
should be
done to allow consumers to support caching
levels. Adding
wording/function as you are
suggesting to our current specification
prevents
such behavior.
We should be concerned about extensibility in the future to
provide a
richer solution. Though, all or
nothing invalidation is both convenient
for the
developer and affords an easy specification, our experience
shows that this ultimately must be coupled with a more flexible
invalidation model where the portlet can explicitly
control each piece
of content to be
invalidated. Though more work, [invalidation] caching
is about optimization and optimization in general involves more
work/a
deeper knowledge to the true nature of
interactions.
-Mike-
Rich Thompson wrote:
>Document: Spec
>Section:
6.2.1.2
>Page/Line: 39/10
>Requested by: Rich Thompson
>Old text:
[insert new paragraph]
>Proposed text: Consumers
invoking either performInteraction() or
>performBlockingInteraction() MUST treat any markup cached for the
>equivalent MarkupParams (i.e. the MarkupParms
structure passed to the
>invocation updated with
any honored newMode or newWindowState requests and
>any returned navigationalState) as if the expiry time had elapsed
unless
>the response includes a new CacheControl
structure indicating the cached
>markup is still
valid.
>
>Reasoning: I
had promised last Wednesday to post a proposal for how
>interaction processing impacts cached markup.
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the
subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>