[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Re: Cookies at XML Europe 2004 -- Call for Particip ation
Elliotte Rusty Harold <elharo@m...> 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 :-(....
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|