- From: Mike Wilson <mikewse@hotmail.com>
- Date: Thu, 18 Jun 2009 10:07:25 +0200
Michael Nordman wrote: > This breakdown is a useful way to think about application state > in the browser. Thanks, it has been very useful to myself as a working model for making vague thoughts of "something missing" into something that is possible to measure and compare. Ideally, some similar kind of overview could be maintained in the HTML5 spec to keep both spec authors and readers sane. > Another axis that could be incorporated into the > model is lifetime. You really hit the nail on the head there. Actually, my initial attempt on a comparison table included a few additional columns: General: - state inherited by cloned browsing context - persistent storage supported - state protected/scoped by origin - state protected/scoped by origin+path - lifetime control Server-control: - state travels to browser in response headers - state travels to browser in response body but I decided to start out with a cut-down version, as otherwise definitely no-one would read my post (it was bad enough with the length of it even being cut down ;-). > There is some overlap between Server- > Controlled and Script-Controlled realms in cookies, applications > definitely have a dependency on that overlap being there. Right, I missed including that in the post. Actually, in my initial table (mentioned above) I didn't split between client- and server-control, but had that as columns instead, so one feature (cookies) could cover both script- and server-needs. I should note that in this initial table of mine, "normal" cookies serve both purposes but http-only cookies only do server-controlled state. Here's an updated table with cookies added: SCRIPT-CONTROLLED STATE Scope Visibility : State construct ----- ---------- --------------------- user agent, invisible : cookies, WS localStorage browsing context, invisible : window.name, WS sessionStorage document, invisible : - history entry, invisible : history state history entry, url, : url hash > There > are two constructs not represented in your writeup, Database and > ApplicationCache. Yes, they felt like somewhat different animals so I didn't include them, maybe that was wrong. All the other ones are some kind of simple data or name/value-paired data so I focused on them. My goal was also to make a matrix that would help us find the missing pieces, by identifying the empty cells. When adding too many different "animals" to the same matrix there will be many empty cells, and it gets harder to see patterns. Do you have ideas on how to incorporate Database and ApplicationCache in the comparisons? > > Possible solutions would be to add a new "documentStorage" to > > WebStorage, or to offer a History.setDocumentState method. > > I see other possibilities with WebStorage too. > "documentStorage" has persistent lifetime + document scope > others... > transient lifetime + document scope (transient does not > survive a browser restart) > transient lifetime + user agent scope "temporaryStorage" > transient lifetime + history entry scope "privateStorage" Interesting ideas! My initial thought was that lifetime could be controlled in a way similar to cookies, ie no lifetime indicates transient lifetime, and for persistent lifetime you set an expiration date/time. Maybe the legacy of cookie expiration doesn't have to be the model here, but it would seem good if some of the suggested extensions are indeed implemented as something cookie-like. mvh Mike
Received on Thursday, 18 June 2009 01:07:25 UTC