[whatwg] Application defined "locks"

[Jeremy Orlow]

On Thu, Sep 10, 2009 at 1:37 PM, Darin Fisher <darin at chromium.org> wrote:

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

I'd count plugins as "trouble APIs".  :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090910/27e1b4a5/attachment-0002.htm>