Now I think about it I see where you were coming from with get:
var x = getNamedStorage('x');
x.onsuccess(function(store) {...});
would make more sense like that... and I guess if you include the onsuccess
callback in one function you get:
getNamedStorage('x', function(store) {...});
I reads be
On 11 January 2011 22:37, Jonas Sicking wrote:
> On Tue, Jan 11, 2011 at 2:11 PM, Keean Schupke wrote:
> > Would each 'name' storage have its own thread to improve parallelism?
>
> Your vocabulary is a bit off since from an API point of view, storage
> areas don't have threads, the execution env
The callback is doing something 'with' the resource you are waiting for. The
callback cannot be called 'without' the resource being available. The 'with'
refers to the 'named storage object' not the registration of the callback.
"with" this named storage object "do" function
Would be how I read
On Tue, Jan 11, 2011 at 6:02 PM, Tab Atkins Jr. wrote:
> On Tue, Jan 11, 2011 at 4:39 PM, Jonas Sicking wrote:
>> On Tue, Jan 11, 2011 at 2:44 PM, Tab Atkins Jr. wrote:
>>> On Tue, Jan 11, 2011 at 2:37 PM, Jonas Sicking wrote:
On Tue, Jan 11, 2011 at 2:11 PM, Keean Schupke wrote:
> wo
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11740
Summary: vbvbcb dcbd fhfdh h hfgh fg h fgh hfg hfghfg hf
Product: WebAppsWG
Version: unspecified
Platform: Other
URL: http://www.whatwg.org/specs/web-apps/current-work/#top
OS/Ver
Now that there's ArrayBuffer will a binary protocol be added?
https://developer.mozilla.org/en/JavaScript_typed_arrays/ArrayBuffer
Just need to say you're using the binary protocol in the handshake. Don't need
length or anything since it would just be a normal TCP stream and someone could
create
On Tue, Jan 11, 2011 at 9:02 PM, Tab Atkins Jr. wrote:
> Python has its "with" keyword, used like "with file = open('foo'):
> doStuffToTheFile(file)", which similarly creates a named resource and
("with open('foo') as file:")
> takes a chunk of code within which the resource is available. I know
On Tue, Jan 11, 2011 at 4:39 PM, Jonas Sicking wrote:
> On Tue, Jan 11, 2011 at 2:44 PM, Tab Atkins Jr. wrote:
>> On Tue, Jan 11, 2011 at 2:37 PM, Jonas Sicking wrote:
>>> On Tue, Jan 11, 2011 at 2:11 PM, Keean Schupke wrote:
would:
withNamedStorage('x', function(store) {...});
m
On 1/11/11 8:02 PM, Glenn Maynard wrote:
The infamous Turkish "I" comes to mind as a portability problem: code
could reasonably create "Info" in one place and read it as "info" in
another, which would be different files in a Turkish locale. Windows
still treats "I" and "i" as the same letter eve
On Tue, Jan 11, 2011 at 5:33 PM, Eric Uhrhane wrote:
> 2) Developers often don't read UA logs. We should fail early on the
> dev box, rather than failing later on the user's machine.
(I guess I just lack sympathy for developers who completely ignore
browser warnings.)
>> - existing filenames th
On Tue, Jan 11, 2011 at 2:44 PM, Tab Atkins Jr. wrote:
> On Tue, Jan 11, 2011 at 2:37 PM, Jonas Sicking wrote:
>> On Tue, Jan 11, 2011 at 2:11 PM, Keean Schupke wrote:
>>> would:
>>> withNamedStorage('x', function(store) {...});
>>> make more sense from a naming point of view?
>>
>> I have a dif
On Tue, Jan 11, 2011 at 3:58 PM, Jonas Sicking wrote:
> With localStorage being the way it is, I personally don't think we can
> ever allow localStorage access in workers.
This makes sense if the storage mutex goes away entirely for
localStorage itself (reflecting current implementations).
If lo
On Tue, Jan 11, 2011 at 2:37 PM, Jonas Sicking wrote:
> On Tue, Jan 11, 2011 at 2:11 PM, Keean Schupke wrote:
>> would:
>> withNamedStorage('x', function(store) {...});
>> make more sense from a naming point of view?
>
> I have a different association for 'with', especially in context of
> JavaSc
On Tue, Jan 11, 2011 at 2:11 PM, Keean Schupke wrote:
> Would each 'name' storage have its own thread to improve parallelism?
Your vocabulary is a bit off since from an API point of view, storage
areas don't have threads, the execution environments in workers and
windows do.
But if your question
Glenn:
Sorry about the slow response; I was on vacation, and am only now catching up.
We've discussed these issues before, see
http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0229.html
for much of the initial discussion. However, you've brought up a new
point that I think is worth
Would each 'name' storage have its own thread to improve parallelism?
would:
withNamedStorage('x', function(store) {...});
make more sense from a naming point of view?
Cheers,
Keean.
On 11 January 2011 20:58, Jonas Sicking wrote:
> With localStorage being the way it is, I personally don't
With localStorage being the way it is, I personally don't think we can
ever allow localStorage access in workers.
However I do think we can and should provide access to a separate
storage area (or several named storage areas) which can only be
accessed from callbacks. On the main thread those call
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11606
Ian 'Hixie' Hickson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11589
Ian 'Hixie' Hickson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11581
Ian 'Hixie' Hickson changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
This is a Last Call transition announcement for Navigation Timing:
http://www.w3.org/TR/2011/WD-navigation-timing-20110111/
Please send comments to public-web-p...@w3.org with [NavigationTiming]
at the start of the subject line by 8 February 2011.
Note: Feedback would be especially
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11570
Ian 'Hixie' Hickson changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
Allow access only from serialized callbacks in workers.
Cheers
Keean
On 11 Jan 2011 14:45, "Jeremy Orlow" wrote:
> So what's the plan for localStorage in workers?
>
> J
>
> On Tue, Jan 11, 2011 at 9:10 AM, Keean Schupke wrote:
>
>> I think I already came to the same conclusion... JavaScript has
So what's the plan for localStorage in workers?
J
On Tue, Jan 11, 2011 at 9:10 AM, Keean Schupke wrote:
> I think I already came to the same conclusion... JavaScript has no control
> over effects, which devalues STM. In the absence of effect control, apparent
> serialisation (of transactions) i
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11730
Art Barstow changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On Mon, Jan 10, 2011 at 9:40 PM, Jonas Sicking wrote:
> On Tue, Dec 14, 2010 at 12:13 PM, Jeremy Orlow
> wrote:
> >
> > On Tue, Dec 14, 2010 at 7:50 PM, Jonas Sicking wrote:
> >>
> >> On Tue, Dec 14, 2010 at 8:47 AM, Jeremy Orlow
> wrote:
> >>>
> >>> Btw, I forgot to mention IDBDatabase.transa
If one handler changes the state who knows what will happen. I guess the
order in which handers are called is significant. That's one advantage to
using a function like "all" to compose callbacks - its very clear what order
they get called in. You could call it 'sequence' to make it even clearer
(t
Looks great, I just tried to stay as close to the current API as possible.
A single handler should definitely be enough. Can, say, a cursor be read
multiple times (if there are several success handlers)? Doesn’t that make
things more complicated?
On Jan 11, 2011, at 10:22 , Keean Schupke wrote:
Comments inline:
On 11 January 2011 07:11, Axel Rauschmayer wrote:
> Coming back to the initial message in this thread (at the very bottom):
> => General rule of thumb: clearly separate input data and output data.
>
> Using JavaScript dynamic nature, things could look as follows:
>
> indexedDB.o
I think I already came to the same conclusion... JavaScript has no control
over effects, which devalues STM. In the absence of effect control, apparent
serialisation (of transactions) is the best you can do.
What we need is a purely functional JavaScript, it makes threading so much
easier ;-)
Ch
I think the idea is that JavaScript should not do unexpected things. The
suggestion to only make local storage accessible from inside callbacks seems
the best suggestion so far.
Cheers,
Keean.
On 11 January 2011 06:20, Felix Halim wrote:
> On Tue, Jan 11, 2011 at 1:02 PM, Glenn Maynard wrote
31 matches
Mail list logo
