Re: ACTION-481 Web Application State Management

Hi Graham:
The disadvantage I am talking about has to do with the fact that history.pushState() and history.replaceState() are new HTML5 facilities that may not be supported by all browsers.
Since these facilities are used to manage the history in situations where the state is bookmarked,
yes, it is specific to state management.

But, perhaps, I did not understand your question correctly.
All the best, Ashok

On 7/27/2011 12:14 AM, Graham Klyne wrote:
> 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 Thursday, 28 July 2011 16:42:32 UTC