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
