- From: Darin Fisher <darin@chromium.org>
- Date: Wed, 9 Sep 2009 21:37:40 -0700
On Wed, Sep 9, 2009 at 9:27 PM, Jeremy Orlow <jorlow at chromium.org> wrote: > 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. > It may not be so easy to disallow showModalDialog. Imagine if you script a plugin inside the transaction, and before returning, the plugin scripts another window, where it calls showModalDialog. There could have been a process hop there. -Darin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090909/dba2a8ad/attachment-0001.htm>
Received on Wednesday, 9 September 2009 21:37:40 UTC