[whatwg] Worker feedback

[Michael Nordman]

I'd like to propose a way forward. Please have an open mind.
The objections your hearing from the chrome world are around the locking
semantics being proposed. In various discussions the terms "evil",
"troubling", and "onerous" have been used to describe what we think about
aspects of those semantics. There are obvious difficulties in providing the
semantics being discussed in a multi-threaded multi-process browser. There
are obvious performance implications. There are limitations imposed on
workers that would otherwise not be an issue. And with the introduction of
these locks today, there would be challenges going forward when trying to
add new features such that deadlocks would not be incurred... our hands
would be getting tied up. So we don't like it... evil, troubling, onerous.

The objections I'm hearing from the firefox world are around providing an
API that is less error prone.

I suggest that we can come up with a design that makes both of these camps
happy and that should be our goal here.

To that end... what if...

interface Store {
  void putItem(string name, string value);

  string getItem(string name);
  // calling getItem multiple times prior to script completion with the same
name is gauranteed to return the same value
  // (unless the current script had called putItem, if a different script
had called putItem concurrently, the current script wont see that)

  void transact(func transactCallback);
  // is not guaranteed to execute if the page is unloaded prior to the lock
being acquired
  // is guaranteed to NOT execute if called from within onunload
  // but... really... if you need transactional semantics, maybe you should
be using a Database?

  attribute int length;
  // may only be accessed within a transactCallback, othewise throws an
exception

  string getItemByIndex(int i);
  // // may only be accessed within a transactCallback, othewise throws an
exception
};


document.cookie;
// has the same safe to read multiple times semantics as store.getItem()


So there are no locking semantics (outside of the transact method)... and
multiple reads are not error prone.

WDYT?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090401/93f8a225/attachment-0002.htm>