Re: ACTION-481 Web Application State Management

ashok malhotra wrote:
> A revised version of Identifying Application State is at
> http://www.w3.org/2001/tag/doc/IdentifyingApplicationState-20110715.html
> This reflects comments from the discussion at the f2f.
> Please read and comment.

Thanks for this.

I have a question concerning:
[[
5.3 Structure of the State URI

The URI that is generated to identify application states can either use query 
parameters or URI paths or it can use fragment identifiers.

If the generated URI uses query parameters or URI paths then, to avoid a page 
reload, history.pushState() and history.replaceState() have to be used to manage 
the browser history. This has the advantage that if the URI is moved and reused 
the entire URI is transmitted to the server and the server can make intelligent 
decisions based on the capabilities of the client. It has the disadvantage that 
these new capabilities may not be supported by all browsers and that may limit 
the reach of the website.
]]

Is there any particular respect in which the disadvantage noted here is specific 
to the state management issue, as opposed to just a general feature of URIs?

Is there any approach to state identification that avoids this disadvantage?

#g
--

Received on Wednesday, 27 July 2011 15:54:41 UTC