IE Team's Feedback on HTML 5.0 DOM Store

HTML 5.0 DOM Store Proposals and Feedback

We're glad to say that IE8 Beta 1 now supports the HTML 5.0 DOM Store<http://www.w3.org/html/wg/html5/#storage>, a simple but powerful storage model. We love the draft's ability to store large amounts of data on the client efficiently and will provide more feedback if necessary once we take a look at the latest iteration of the draft. IE8 Beta 1's implementation is based on an earlier version as stated in our release notes<http://support.microsoft.com/kb/949787>. It's challenging for us to implement a moving target (draft) since the dates of expected deliverables are not committed. Nonetheless, we think this is a great feature and implemented it<http://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=ie8whitepapers&ReleaseId=581> for Beta-1.

Meanwhile, we have feedback for the draft that we feel and hope will contribute to the existing repository of web developer's tools. Here are a few enhancements that we've implemented. We think these features are good for developers and want to add them to the spec. MSDN is being updated so for more details please refer to the API.<http://msdn2.microsoft.com/en-us/library/cc197062(VS.85).aspx>

Storage Checker<http://msdn2.microsoft.com/en-us/library/cc197016(VS.85).aspx>
Storage.remainingSpace
A straightforward and popular request, this API provides a script to check the remaining persistent storage spec available to it, in bytes. It's a very useful feature to allow pages to manage their store better.

*         <Open Issue> We currently return bytes but perhaps returning the number of characters is more useful? We'd love to hear thoughts here...

Clear All API<http://msdn2.microsoft.com/en-us/library/cc288131(VS.85).aspx>
Storage.clear()
An obvious benefit for the persistent store, unlike removeItem<http://msdn2.microsoft.com/en-us/library/cc197047(VS.85).aspx>, this API removes all key/value pairs accessible to that script without requiring costly iteration over all data entries.

Asynchronous model for DOM Storage:<http://msdn2.microsoft.com/en-us/library/cc288674(VS.85).aspx>
The spec calls for atomic setItem() and removeItem() with respect to changes to the data storage area. This is valuable since it ensures that data is written to disk successfully. One of the major differences today between what we've implemented is that we went down an "asynchronous" path.  This is because there are significant performance advantages if committing to the disk can be delayed while providing the data instantly from memory.  Our model is exposed the same as a synchronous model to the web developer so there should be no differences to the developer who is interested in programming it using no new APIs other than that specified in the HTML 5.0 spec.
Here are some of the reasons why the asynchronous model was chosen:

1. It offers much better performance without sacrificing the persistence to disk  -- we will fire an event to confirm commit so web applications can listen to the event when persistence is a concern.

2.  Our customer outreach leads us to believe that the DOM Storage is primarily used as local cache to improve responsiveness. The performance cost of synchronous storage in our opinion outweighs the need for guaranteed persistence.

3.       It avoids a possible hang in the UI thread if the operation takes long time and therefore makes the browsing experience more fluid.





Hence we created an async model. As far as the web developer is concerned, the data will be available immediately from memory when the onstorage event it fired so the behavior is the similar and no new APIs are needed, hence its backwards compatible with other implementations. In addition, an onstoragecommit event is fired for developers who want to ensure the data is persisted to disk successfully.



Begin/Commit<http://msdn2.microsoft.com/en-us/library/cc197036(VS.85).aspx>

Storage.begin()

Storage.commit()


It's an application level concept that web authors who want a set of values to be committed at once can use. Data is either committed in its entirety (batch commit) or not. This is especially critical given that DOM Storage is primarily used for name/value pair operations and many applications need a set of name/value pairs to define a consistent state.


--
Sunava Dutta
Program Manager (AJAX) - Developer Experience Team, Internet Explorer
One Microsoft Way, Redmond WA 98052
TEL# (425) 705-1418
FAX# (425) 936-7329