Re: DOM Storage feedback

On Jun 18, 2008, at 10:38 PM, Ian Hickson wrote:

>
>
> It would be useful to get feedback from other implementors on this.

[...]

>
>
>>> The API is designed in such a way that UAs can implement a lazy  
>>> commit
>>> on the back end, but this should not be exposed to the author --  
>>> there
>>> is no reason for the author to need to know whether the data is in
>>> RAM, flash storage, disk storage, remote tape storage, or whatever.
>>
>>
>> There is clearly an advantage to expose this concept to authors --  
>> just
>> like they need to know network can be slow so better use async XHR
>> rather than sync XHR -- storage operation can be very slow. Sync DOM
>> Storage operation is a potential hang point,
>
> The idea is that the storage is asynchronous (and under the control  
> of the
> UA), but that the API appears synchronous. That is, as soon as one  
> script
> sets a storage item to a particular value, the setter will return  
> with no
> latency, and all attempts from any frames to read that same storage  
> item
> will give the new value back. It doesn't have to be stored to disk
> immediately, however. Since this is a simple name/value text-only  
> API, it
> is trivially cached in memory.
>
> What's the use case for the event saying when the item actually hits  
> the
> disk? Also, what would that actually mean? The "disk" could be up in  
> the
> cloud (e.g. the user could have mounted an Amazon S3 service account  
> as a
> local disk), in which case the Web browser really has no idea when the
> bytes have hit the raw iron.

In WebKit we have implemented DOM Storage with a synchronous API, but  
ahead-of-time read and lazy writeback, using something roughly like  
the strategy Hixie describes. We don't have an event for when the data  
has actually been written out to disk because we could not see a use  
for it. We guarantee to store it unless the browser crashes, and we  
show the new value to anyone accessing the storage, so it doesn't make  
a differece.

>
>
>
>>>> Storage.begin()
>>>>
>>>> Storage.commit()
>>>
>>> In particular, these methods and the associated events should not be
>>> provided to authors. The SQL database API is already capable of
>>> handlign this. Authors who wish to have transactions are almost
>>> certainly going to want other features too, such as types, database
>>> schemas, etc.
>>>
>>> If you insist on keeping these features, please do mark them as
>>> Microsoft-proprietary by prefixing them with "ms" or some such, as  
>>> in,
>>> "msBegin()", "msCommit()", etc, so that authors can clearly see that
>>> these APIs are non-standard, and so that we don't have any conflicts
>>> with future extensions to the API.
>>
>> I have to disagree that customers who wants begin()/commit() should  
>> use
>> SQL API.  If the argument holds, why not simply get rid of DOM  
>> Storage
>> feature completely since customer can just use SQL API?
>
> This was considered, but there seemed to be a need for a middle ground
> between cookies and a full SQL-like database. Also, the DOM Storage
> sessionStorage feature has no analogy in the SQL Database API.
>
> The features that distinguish the DOM Storage API from the SQL  
> Database
> API are that the API appears synchronous, allowing much simpler
> interaction between frames; that the API supports a sessionStorage
> feature; and that the DOM Storage mechanism is significantly simpler  
> and
> thus provides a much lower barrier to entry.

In WebKit we have both the Database Storage and DOM Storage APIs, and  
we see them as complementary. Authors are interested in both for  
different use cases. I do not think it makes sense to add transaction  
support to the DOM Storage API.

>> This request come from one of our top customers when we discuss about
>> adoption of DOM Storage feature. They really want to make sure their
>> state is consistent without going through a lot of extra efforts.
>
> Could you elaborate on the use cases?
>
> It would also be interesting to hear from other browser vendors on  
> their
> opinions on this.

I would recommend the Database Storage to anyone with a need for  
strong transactional consistency guarantees. That being said, it  
should not be possible for other windows to observe a different state  
since script execution has to happen serially, so there should already  
be weak consistency.

>
>> For instance, to cache an email, you would want to cache complete
>> headers (e.g. From, To, Subject, Sent) and body instead of only  
>> part of
>> them.
>
> For e-mail storage, you really want to use a database mechanism, not  
> the
> name/value pairs. Using the DOM Storage API for e-mails is like  
> using a
> paper bag as a shipping crate.

I agree on this one. I would not recommend using DOM Storage for  
structured data with multiple interesting fields.

Regards,
Maciej

Received on Thursday, 19 June 2008 06:47:47 UTC