Monday, September 05, 2005
Really Simple History: Bookmarking and Browser History Support for AJAX Applications
I have posted a new specification for AJAX applications I call Really Simple History:
"This document is a strawman proposal for a very simple browser-supported API for AJAX applications to support bookmarking and the back and forward buttons. It is meant to be implemented by both browser manufacturers as well as developers creating emulation libraries to provide such support. It is in alpha draft form and is open to comments. It's operating principles are Keep It Simple Stupid (KISS) and to create APIs that work in the real world."
The spec is super simple, as its name implies, and is straightforward to read. Give it a gander and provide some feedback. I'm going to create an emulation shim for parts of the API soon.
"This document is a strawman proposal for a very simple browser-supported API for AJAX applications to support bookmarking and the back and forward buttons. It is meant to be implemented by both browser manufacturers as well as developers creating emulation libraries to provide such support. It is in alpha draft form and is open to comments. It's operating principles are Keep It Simple Stupid (KISS) and to create APIs that work in the real world."
The spec is super simple, as its name implies, and is straightforward to read. Give it a gander and provide some feedback. I'm going to create an emulation shim for parts of the API soon.
Comments:
Links to this post:
<< Home
I'm not convinced about not using history object. history.go(-1) works, so that object is relative to current page.
So far every cross-something feature caused series of vulnerabilities in browsers. I think vendors won't like idea of multiple add() calls, persistent events and possiblity to store objects.
Besides stored object is either dangerous or not really useful.
Not useful when it can't keep its references to DOM, events and other objects. Then it just becomes associative array.
If it can - it's tricky how to store/restore them and how to keep it secure and stable. It begs for invalid pointers, use of freed memory, and bugs in garbage collector (first exploit ready: dhtmlHistory("pwned",dhtmlHistory);)
How do you address privacy issues? Who, what, when and how long can store data?
Post a Comment
So far every cross-something feature caused series of vulnerabilities in browsers. I think vendors won't like idea of multiple add() calls, persistent events and possiblity to store objects.
Besides stored object is either dangerous or not really useful.
Not useful when it can't keep its references to DOM, events and other objects. Then it just becomes associative array.
If it can - it's tricky how to store/restore them and how to keep it secure and stable. It begs for invalid pointers, use of freed memory, and bugs in garbage collector (first exploit ready: dhtmlHistory("pwned",dhtmlHistory);)
How do you address privacy issues? Who, what, when and how long can store data?
Links to this post:
<< Home
Subscribe to Posts [Atom]
