- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Thu, 10 Sep 2009 13:27:49 +0900
On Thu, Sep 10, 2009 at 1:13 PM, Darin Fisher <darin at chromium.org> wrote: > On Wed, Sep 9, 2009 at 6:46 PM, Aaron Boodman <aa at google.com> wrote: > >> On Wed, Sep 9, 2009 at 11:30 AM, Aaron Boodman<aa at google.com> wrote: >> > I see. >> > >> > So you are suggesting the localStorage could have zero concurrency >> > guarantees and it is simply up to the developer to arrange things >> > themselves using this new primitive. >> > >> > That is an interesting idea. You're right that it overlaps with the >> > ideas that inspired shared workers, and the global script proposal. >> >> Ok, after thinking about this for a day, I'm going to say I think this >> is a very cool idea, and a worthwhile addition, but I don't think it >> should substitute for having the local storage API work correctly by >> default. >> >> The web platform is supposed to work for developers of all experience >> levels. If we make local storage have no concurrency guarantees, it >> will seem like it works in the overwhelming majority of cases. It will >> work in all SELUAs, and it will only NOT work in MELUAs in cases that >> are basically impossible to test, let alone see during development. >> >> We have tried hard with the design of the web platform to avoid these >> sort of untestable non-deterministic scenarios, and I think it is to >> the overall value of the platform to continue this. >> >> Therefore, my position continues to be that to access local storage, >> there should be an API that asynchronously acquires exclusive access >> to storage. >> >> - a >> > > > Yeah, if you had to call an API that asynchronously acquires exclusive > access > to storage, then I believe that would nicely address most of the issues. > It is the > solution we have for database transactions. > > I say "most" because I'm not sure that it eliminates the need to drop the > storage > mutex in the showModalDialog case. > > If I call showModalDialog from within a database transaction, and then > showModalDialog > tries to create another database transaction, should I expect that the > transaction > can be started within the nested run loop of the modal dialog? If not, > then it may cause > the app to get confused and never allow the dialog to be closed (e.g., > perhaps the close > action is predicated on a database query.) > > Nested loops suck. showModalDialog sucks :-) > We could just disallow showModalDialog and any other trouble APIs like that during localStorage and database "transactions". Doing so seems better than silently dropping transactional semantics. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090910/4198b33f/attachment.htm>
Received on Wednesday, 9 September 2009 21:27:49 UTC