[whatwg] html5 state handling: overview and extensions

[Mike Wilson]

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