Andre,
Thanks for the clarification.
I wonder how much flexibility the Consumer has in determining what a user
agent is. For example: do two separate browser windows / two separate browsers /
two separate machines count as one or more end-user / user agent. One may argue
that the Consumer may use this flexibility to avoid the need to synchronize
requests to the browser while initCookie is happening - in the worst case, those
parallel requests will behave like two separate user agents, and since they are
most likely to come from different browser windows anyway, this may not be that
bad.
(I haven't looked at the spec to see what it says on the topic
though.)
In any case, it seems that cache invalidation mandates Consumer
synchronization (a) at a MUST level (since data integrity is at hand) (b)
not just for "legacy" apps (which is where initCookie comes in). So a decision
needs to be made whether it's justified given the former F2F decision mentioned
by Mike.
Eilon
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>
|