Hi,
Before anything else, thanks for this detailed and quite complete
explanation.
Le 03/09/2012 23:32, Jonas Sicking a écrit :
The other thing that I wanted to talk about is use cases. It has been
claimed in this thread that synchronous message passing isn't needed
and that people can just
On 9/4/12 5:23 AM, David Bruant wrote:
Also, I wish the demand came from the people who do work on Emscripten
or Mandreel
As far as I know, what Jonas is saying about Emscripten did come from
the Emscripten folks. I've certainly seen them say it in bugs in the
recent past. No guessing
Le 04/09/2012 14:34, Boris Zbarsky a écrit :
On 9/4/12 5:23 AM, David Bruant wrote:
Also, I wish the demand came from the people who do work on Emscripten
or Mandreel
As far as I know, what Jonas is saying about Emscripten did come from
the Emscripten folks. I've certainly seen them say it
On 9/4/12 8:54 AM, David Bruant wrote:
Ok I wasn't aware of that. Do you have bug numbers in mind by any chance?
I don't offhand, unfortunately. Would have to search.
-Boris
On Tue, Sep 4, 2012 at 4:23 AM, David Bruant bruan...@gmail.com wrote:
The proposed solution here throws away all benefits of async code to
reduce the complexity of writing async code by... writing sync code.
I wish we'd explore more solutions to make async more workable rather than
throwing
Le 04/09/2012 17:03, Glenn Maynard a écrit :
On Tue, Sep 4, 2012 at 4:23 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
The proposed solution here throws away all benefits of async code
to reduce the complexity of writing async code by... writing sync
code.
On Tue, Sep 4, 2012 at 10:32 AM, David Bruant bruan...@gmail.com wrote:
Cognitive load is the only one mentioned so far. It is a serious issue
since for the foreseeable future, only human beings will be writing code.
However, as said, there are solutions to reduce this load.
I wish to share
This is a Call for Consensus to publish a First Public Working Draft of
the DOM Parsing and Serialization spec using the following ED as the
basis http://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html.
This CfC satisfies the group's requirement to record the group's
decision to request
Le 04/09/2012 18:46, Glenn Maynard a écrit :
On Tue, Sep 4, 2012 at 10:32 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Cognitive load is the only one mentioned so far. It is a serious
issue since for the foreseeable future, only human beings will be
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18772
Summary: Should getAllResponseHeaders() end with \r\n?
Product: WebAppsWG
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
On Tue, Sep 4, 2012 at 12:49 PM, David Bruant bruan...@gmail.com wrote:
I'm sorry, but I have to disagree. Have you ever used promises in a
large-scale project?
I've been amazed to discover that promise-based API are ridiculously much
easier to refactor than callback-based API. Obviously,
Le 04/09/2012 20:47, Glenn Maynard a écrit :
On Tue, Sep 4, 2012 at 12:49 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
I'm sorry, but I have to disagree. Have you ever used promises in
a large-scale project?
I've been amazed to discover that promise-based
On Tue, Sep 4, 2012 at 2:23 PM, David Bruant bruan...@gmail.com wrote:
Tooling isn't perfect for async debugging. It's being worked on. Yet it
hasn't prevented web devs from buiding (and debugging) event-based code.
Developers work in lots of bad environments and get stuff done anyway.
That's
On Mon, 3 Sep 2012, Glenn Maynard wrote:
- Add an internal flag to MessagePort, blocking permitted, which is
initially set.
- When a MessagePort port is transferred from source to dest,
- If source is an ancestor of dest, the blocking permitted flag of
port is cleared. (This is a down
[Forwarding a response from Alon Zakai, who is behind Emscripten and
CC'ing him]
There is also another use-case which has been brought up. As the
web
platform is becoming more powerful, people have started converting
code written for other platforms to javascript+html.
By html, here, do
Alon Zakai wrote:
Technically it might
be possible to automatically rewrite such code to use asynchronous
coding patterns, but so far I don't think anyone has managed to do
that.
Naively, I would say, that once we've paid the price to compile code
from one language to another, you're not
David Bruant wrote:
I can imagine, it sounds hard indeed. Do you have numbers on how it
affects performance? Or an intuition on these numbers? I don't need to
be convinced that it affects performance significantly, but just to get
an idea.
This is not going to be easy to estimate, but you
On Tue, Sep 4, 2012 at 3:11 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 3 Sep 2012, Glenn Maynard wrote:
- Add an internal flag to MessagePort, blocking permitted, which is
initially set.
- When a MessagePort port is transferred from source to dest,
- If source is an ancestor of
On Mon, Sep 3, 2012 at 10:55 PM, Glenn Maynard gl...@zewt.org wrote:
I suspect there's a way to make the general-case version work, though.
To restate this by itself instead of as a delta:
- Add an internal flag to MessagePort, blocking permitted, which is
initially set. Add a value previous
On Tue, Sep 4, 2012 at 1:59 PM, Brendan Eich bren...@mozilla.org wrote:
David Bruant wrote:
I can imagine, it sounds hard indeed. Do you have numbers on how it
affects performance? Or an intuition on these numbers? I don't need to
be convinced that it affects performance significantly, but
On Sat, Sep 1, 2012 at 11:49 AM, David Bruant bruan...@gmail.com wrote:
Also, I don't think I have seen mentionned use cases of things that are
not possible without a Sync API. Everything presented is already
possible (sometimes at arguably high costs like Glenn Maynard's use case
in
Hello,
I have a quick document correction for: http://www.w3.org/TR/IndexedDB/
As far as I can tell, there is no openIndex method as shown in the var
index example below. I think it should be objectStore.index() ? Also, I
am assuming that the var vtx is a versionchange transaction object, but
The current draft of XHR2 doesn't allow clients to set the UA header.
That's unfortunate, because part of the intent of the UA header is to identify
the software making the request, for debugging / tracing purposes.
Given that lots of libraries generate XHR requests, it would be natural for
+1
roBman
On Wed, 5 Sep 2012 14:03:35 +1000
Mark Nottingham m...@mnot.net wrote:
The current draft of XHR2 doesn't allow clients to set the UA header.
That's unfortunate, because part of the intent of the UA header is to
identify the software making the request, for debugging / tracing
On Mon, Sep 3, 2012 at 8:45 AM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Sep 3, 2012 at 1:24 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Aug 30, 2012 at 2:18 PM, Jonas Sicking jo...@sicking.cc wrote:
...
...
But I'm also not very worried about small differences in
25 matches
Mail list logo
