RE: [xml-dev] Re: Cookies at XML Europe 2004 -- Call for Particip ation

["Hunsberger, Peter" <Peter.Hunsberger@stjude.org>]

Elliotte Rusty Harold <elharo@metalab.unc.edu> asks:

> At 10:45 AM -0600 1/6/04, Hunsberger, Peter wrote:
> 
> >How do you balance between tracking flow with stateless 
> systems (as in 
> >shopping cart check out) and caching (performance optimization)?  If 
> >you don't use Cookies you've got to write some unique state 
> identifier 
> >into the response/request cycle.  Preferably not in the URL so as a 
> >parameter to be passed back on the POST.  Since this 
> identifier must be 
> >unique for each user you've now destroyed the ability to 
> cache the page 
> >generically and instead must generate it uniquely for each 
> user.  I'd 
> >argue the only rational choice is cookies (preferably 
> >non-persistent)...
> 
> I'm not sure I quite understand you here. Perhaps you could give a 
> more concrete example? Most shopping cart apps I'm aware of are very 
> dynamic and customize heavily per user and per page. Otherwise how 
> could you show the user what's in their basket? So I don't think 
> you'd want to cache this at all, with or without cookies, but maybe 
> I'm missing something?

Hmm, shopping carts are probably a bad example.  

We have this problem in our system, but without diving into all the
details (Clinical Research) let me put I this way: we have many screens
that can potentially be used to POST data, for example a new surgery or
chemo result.  However, 90% of the time the user just wants to see the
list of things performed to date.  So for us, almost all screens are
potentially part of a work flow, but 90% of the time they are static
data.  We only want to invalidate the cached image (on the server side)
when a real update is done.  The rest of the time, we do however have to
be able to associate any given POST with a specific step in a work flow
(independent of any authentication we may also have to perform).

Thinking about it I can see that our use case is pretty strange, but the
generic issue is screens where there is a 3rd dimension to what data can
be displayed at any given point.  In our case, a given user might be
authorized to see a specific piece of data in one context but not in
another where they could associate it with some unique identifier and
learn the identity of a patient that is supposed to be confidential. We
could sort it all out by dynamically recreating the data that lead to
the generation of any given screen for both the GET and the POST, but
now we've got a different performance issue: the context generation is
expensive in our case.  The way to get performance is to have a unique
key that travels across the GET/POST cycle that uniquely identifies an
already generated context.

Somehow I don't think that clears things up :-(....