On Fri, Mar 20, 2009 at 3:10 PM, Aaron Boodman a...@google.com wrote:
I think the best option is to make access to localstorage asynchronous
for workers. This reduces the amount of time a worker can hold the
localstore lock so that it shouldn't be a problem for normal pages. It
sucks to make
Hi Drew,
I definitely think that a lot of what you are proposing here is very
interesting. And, as you mention, much of it needs user approval.
However, I don't think we can use UI as simple a what we use for
enabling popups. The reason is that it's something that is IMHO too
easy to social
For implementors:
The size attribute gives the average number of glyphs that the reader of the
page will be able to see when the control is rendered and completely filled
with text. (This depends on the language of the control and the current
style and accounts for ligature-driven scripts like
On Sat, Mar 21, 2009 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote:
What we could do, is to have an API like
getLocalStorage(callback);
This function returns immediately, but will then call the callback
function as soon as the localStorage becomes available and the lock
been acquired.
That might work. Is it feasible for user agents to enforce limits on how
long a callback is allowed to run holding the lock? That way workers can't
starve normal pages from accessing their local storage.
-atw
On Sat, Mar 21, 2009 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Mar
On Sat, Mar 21, 2009 at 9:41 AM, Drew Wilson atwil...@google.com wrote:
That might work. Is it feasible for user agents to enforce limits on how
long a callback is allowed to run holding the lock? That way workers can't
starve normal pages from accessing their local storage.
It seems like they
Ian,
Anyway I thank you for your careful consideration and encouragement of
another activities.
Basically web signature must be implemented by browser venders because of an
example of XKMS's fail that Anders indicated. So we have to consider how to
do is cost effective and I think form
HTML5 originally included a section about resource identifiers
processing. A few days ago that section was extracted into the W3C
editor draft of Web Addresses. I noticed it and remembered that I had
read once something like that.
Precisely, what I once read is http://www.w3.org/TR/leiri, a note
On Sat, Mar 21, 2009 at 9:38 AM, Aaron Boodman a...@google.com wrote:
On Sat, Mar 21, 2009 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote:
What we could do, is to have an API like
getLocalStorage(callback);
This function returns immediately, but will then call the callback
function as
On Sat, Mar 21, 2009 at 9:41 AM, Drew Wilson atwil...@google.com wrote:
That might work. Is it feasible for user agents to enforce limits on how
long a callback is allowed to run holding the lock? That way workers can't
starve normal pages from accessing their local storage.
I don't think it
As a side note, if we do go with this async lock acquiring, we could
add an API like:
getLockedFeatures(callback, 'localStore', 'cookie');
This would be an asynchronously grab locks to multiple features and
only call the callback once all of them have been acquired. This would
allow computations
On Fri, Mar 20, 2009 at 3:29 PM, Ian Hickson i...@hixie.ch wrote:
On Sat, 7 Mar 2009, Jonas Sicking wrote:
document.cookies can't change in the middle of an execution. I.e. a
script like:
a = document.cookie;
b = document.cookie;
alert(a === b);
will always show 'true'.
On Mon, 9 Mar
On Sat, Mar 21, 2009 at 1:51 PM, Jonas Sicking jo...@sicking.cc wrote:
The problem with synchronously grabbing the lock is that we can only
ever have one feature that uses synchronous locks, otherwise we'll
risk dead-locks.
Say that we make document.cookie behave the same way (to prevent
13 matches
Mail list logo
