W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [XHR2] Disable new response types for sync XHR in Window context

From: Matt Shulman <mattsh@google.com>
Date: Wed, 16 Nov 2011 09:10:03 -0800
Message-ID: <CAMuN6bzDYBZnozT5Z8CebM2aunpS+TpAt2KXJwYeU5BiPdrwEg@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Anne van Kesteren <annevk@opera.com>, Jonas Sicking <jonas@sicking.cc>, Webapps WG <public-webapps@w3.org>, Olli Pettay <Olli.Pettay@helsinki.fi>, "olli@pettay.fi" <olli@pettay.fi>
On Wed, Nov 16, 2011 at 8:20 AM, Glenn Maynard <glenn@zewt.org> wrote:
> On Wed, Nov 16, 2011 at 11:10 AM, Matt Shulman <mattsh@google.com> wrote:
>>
>> I sometimes like to write code in the window context (where debugging
>> support is much better) before moving it to a web worker, so it would
>> be awkward if the sync options differed on xhr between the two.
>> (Analogous to this - I remember once i was trying to use the new
>> FileSystemSync API and during development it would have been much
>> easier if it had been available in the window context, even though
>> eventually I planned to move the code to a worker.)
>
> Improving debugging support in workers is a saner fix for this.  Nobody
> wants to expose new synchronous APIs like FileSystemSync to Window.
Good point.  I'm just saying though that sometimes it's nice to be
able to experiment with new APIs without needing to immediately worry
about workers and postMessage.

Related, if there do need to be differences in APIs or allowable
options between window and webworker, it would be really nice if the
errors clearly stated that's the problem (e.g., something like "xhr
sync option only available in worker" would be more helpful than
"invalid access").

>
> --
> Glenn Maynard
>
>
>
Received on Wednesday, 16 November 2011 17:10:33 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT