Re: Detailed review of 4.11. Client-side persistent storage

On Fri, 11 Jan 2008, Mihai Sucan wrote:
> 
> The spec changed quite much since I sent the email. Mainly, the 
> StorageItem interface is gone, thus the wish for adding the dateModified 
> and dateCreated properties is no longer applicable.
> 
> In the current form of the spec, this is acceptable. Nonetheless, it 
> seems to me "overkill" to be required to use the SQL API for such 
> trivial needs.
> 
> How about adding the getInfo(key) method on the Storage object? This 
> could provide details about the key, such as dateModified, dateCreated, 
> lastUrl (the exact URL of the last page which updated the item).

I guess we can add this in a v2. I've made a note of it. I'd rather not 
add it straight away.


> > The concern is that there may be a lot of changes (especially with 
> > session storage). I'd be interested in hearing from authors who wish 
> > to use this API, though. What do you envisage doing with it that may 
> > require detailed notifications of changes across windows?
> 
> Well, as a Web developer having the storage event notifying me there 
> were some changes is quite useless.
> 
> Imagine this scenario: why would anyone choose to have an event listener 
> for 'storage'? What's the use of knowing that one or more of, perhaps, 
> hundreds of storage items changed, without knowing which? I envision 
> using the listener *only* for when I need to re-read a specific key (or 
> more than one).

Ok, changed it. Is it more useful now?


> > > How are scripts supposed to work when the "disk quota is full"? That 
> > > should be defined in the spec.
> > 
> > How do you mean?
> 
> I mean, a script should be able to check if the disk quota is full or 
> not, such that the author of the document can inform the user.

To some extent this is now possible, since setItem() returns false if it 
fails (though how that interacts with the implied setter, I'm not sure -- 
implementation feedback would be useful here: is it even possible to do 
this sensibly? What should I do here?).


> > > An idea would be to have a new boolean attribute for the Storage 
> > > object: isWritable. This would false when "disk quota is full", or 
> > > true otherwise.
> > 
> > Typically the disk quota is never actually exactly full. e.g. the 
> > usage could be at 995 bytes, the quota at 1000 bytes, so adding an 
> > ASCII string of 4 characters could work but adding a chinese string of 
> > 4 characters could fail (e.g. if the system used UTF-8).
> 
> This is a matter of details.
> 
> The UA should provide the means of checking 'free space' in bytes of 8 
> bits. It's up to the author to know how many characters he can write - 
> he knows the character set and encoding.

Actually he doesn't know the character encoding, nor does he know if data 
is stored efficiently, nor how much overhead there is, nor what 
compression scheme is used. Indeed, even the user agent might not be able 
to find out this kind of information easily.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 9 February 2008 08:44:36 UTC