While
I can't speak for all potential consumers, one reason I fundamentally do not
like initCookie() is that a consumer must hold up other requests while an
initCookie request / response is pending. This synchronization is on a per-User
basis (or possibly for just one page, e.g. for anonymous
users) and is likely to be scoped by a consumer side Web
session.
initCookie() then returns a web cookie value that needs to
be maintained consumer side and I was trying to make the point that, for
some possible consumers, tracking last interaction / expires times would be a
similar coordination (for the perUser UserScope case).
regards,
Andre
Andre,
Can you elaborate on why initCookie implies synchronization at a MUST
level on the Consumer end?
Eilon
Our initCookie() already implies a synchronization, on a per-user
basis, at the consumer. As we therefore already have a consumer side
serialization requirement, the perUser "perform[Blocking]Interaction()
expires cached markup" case should be supportable, even in load balanced
consumers at the page level.
But we should look into relaxing the expires requirement for the
forAll (user scope) case (a SHOULD for the all user scope?)
and possibly also allowing small time based inconsistencies in the perUser
caching scope case. Like initCookie() and our performBlockingInteraction()
page blocking semantics, we may then end up saying very little about
real end users who may have multiple consumer side
sessions...
regards,
Andre
I completely agree.
One example brought in the F2F was that of a
load-balanced (a.k.a., clustered) Consumer, who - if we enforce an
invalidation algorithm - MUST communicate to the other servers in the
clusters in order to discard an invalidated cached, and handle it
consistently in a concurrent environment (race conditions
etc.).
Hopefully nothing else in the spec mandates
intra-cluster communication at the Consumer level, and if that's the case,
we probably want to deal with it in a well-thought-of fashion, as Mike
suggested.
Eilon
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>
|