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

Hello Ian!

Thanks for your reply.

Le Sat, 09 Feb 2008 10:44:14 +0200, Ian Hickson <ian@hixie.ch> a écrit:

> 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.

Thanks for noting this idea.


>> > 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?

It's much better now. The storage event is now finally useful. Thanks.


>> > > 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?).

Here's an idea: add a property to the Storage object, "lastError". The  
property is updated in case of errors when using the implied  
getter/setter, also when using the rest of the defined methods. This  
should be sufficient.




-- 
Mihai Sucan
http://www.robodesign.ro

Received on Saturday, 9 February 2008 10:11:54 UTC