RTC in Web workers

[Charles Pritchard]

Should RTC data channels be available in Workers and/or SharedWorker?

Mainly:
self.RTCPeerConnection
self.RTCSessionDescription

WebSocket and XHR are available, seems like RTC ought to be but isn't.

-Charles

Re: Sync IO APIs in Shared Workers

[Glenn Maynard]

On Fri, Nov 22, 2013 at 11:55 AM, Jonas Sicking  wrote:

> On Fri, Nov 22, 2013 at 7:54 AM, Glenn Maynard  wrote:
> > But, we should explore the use cases more thoroughly first, to see if
> this
> > is really needed.  An alternative is to just terminate() the whole worker
> > and start a new one.  That's not very elegant, but it's very simple and
> > robust: you don't end up with synchronous APIs throwing exceptions
> > unexpectedly and worker code having to clean up after it.  If the work is
> > expensive enough that you need to cancel it, the cost of spinning up a
> new
> > worker is negligible.
>
> What data are you basing this statement on?
>

If starting a worker is so expensive that this this is a real problem, that
seems like a bug.  If somebody is arguing that we should add a new API
because creating a new worker is slow, then that's an optimization
argument, and the burden of proof is on the claim that we need an
optimization, not that we never do.


> > The proposal is to allow polling a MessagePort, retrieving the next
> message
>
> without having to return to the event loop.
>
> I don't like that solution since it's very similar to spinning event
> loops in deep call stacks. Having worked on code bases which does
> event loop spinning on deep call stacks it's a horror I wouldn't want
> to impose on anyone.
>

I don't think they're comparable.  Spinning the event loop may have
unrelated, unexpected side-effects, since it'll run tasks from any event
source.  This wouldn't have any effects like that at all; it would just
check for messages on a specific MessagePort, and pop off and return the
first one.  It wouldn't pull a message from any port other than the one
you're working with.

>> One possible action here would be to disallow sync APIs in shared
> >> workers for now. This way we can use dedicated workers as a test bed
> >> to see if sync APIs are a problem, and if they are, if that problem
> >> can be fixed.
> >
> > This will just make people proxy messages from the shared worker to a
> > dedicated worker, so nothing would change.  I don't think making shared
> > workers more different from dedicated workers than they have to be makes
> > much sense.
>
> "People can already do things the wrong way" is a terrible argument
> for introducing more ways of doing it the wrong way. The same argument
> could be used to say that we should add sync IO APIs on the main
> thread. It's already the case that you can write pages whose UI
> doesn't respond until you get a result back from a worker or an async
> IO operation.
>

I'm not convinced that synchronous work in shared workers *is* always "the
wrong way".  For example, sharing client-side autocomplete in a single
shared worker may be fine, since the user isn't going to be typing into two
tabs simultaneously.

And no, that's not the argument at all.  The argument is that this is
trivial to sidestep.  The lack of sync APIs on the UI thread is hard or
impossible to sidestep.

-- 
Glenn Maynard

[testing] Seeking Test Facilitator(s) for Indexed Database API

[Arthur Barstow]

[ Bcc: public-webapps-testsuite ]

Hi All,

We need help with the Indexed Database API testing effort. The general 
expectations for a "Test Facilitator" (TF) are defined in the testing 
Roles wiki [Roles]. For this spec, one of the first steps is to review 
the various submissions and recommend the set of tests WebApps should 
use to test the [CR] (and identify high priority gaps if there are any). 
After we have agreement on this set, those tests will need to be 
reviewed and the review can be done by multiple people.


Group submissions:

* Opera: 
* Microsoft: 
* Ms2ger: 

TestTTWF Paris submissions:

* BaptisteFontaine: 
* ChristopheCharles: 
* dgrogan: 
* rhuet: 

Please contact me if you can commit to helping with this effort and you 
have `relevant` experience.


-Thanks, ArtB

[Roles] 
[CR] 


 Original Message 
Subject: 	ACTION-704: Find another test facilitator for idb spec (Web 
Applications Working Group)

Date:   Tue, 12 Nov 2013 03:13:17 +
From: 	ext Web Applications Working Group Issue Tracker 


Reply-To:   Web Applications Working Group 
To: 



ACTION-704: Find another test facilitator for idb spec (Web Applications 
Working Group)

http://www.w3.org/2008/webapps/track/actions/704

On: Arthur Barstow
Due: 2013-11-19

If you do not want to be notified on new action items for this group, please 
update your settings at:
http://www.w3.org/2008/webapps/track/users/7672#settings

Re: Sync IO APIs in Shared Workers

[Jonas Sicking]

On Fri, Nov 22, 2013 at 7:54 AM, Glenn Maynard  wrote:
> But, we should explore the use cases more thoroughly first, to see if this
> is really needed.  An alternative is to just terminate() the whole worker
> and start a new one.  That's not very elegant, but it's very simple and
> robust: you don't end up with synchronous APIs throwing exceptions
> unexpectedly and worker code having to clean up after it.  If the work is
> expensive enough that you need to cancel it, the cost of spinning up a new
> worker is negligible.

What data are you basing this statement on?

>> Something else that could improve responsiveness while still allowing
>> people to write synchronous code is the ability to check if there are
>> pending messages on a channel without having to return to the event
>> loop. That way the code can keep running until there's a message to
>> process, and only return to the event loop when there is.
>
> http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1075.html
> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0967.html
>
> The proposal is to allow polling a MessagePort, retrieving the next message
> without having to return to the event loop.

I don't like that solution since it's very similar to spinning event
loops in deep call stacks. Having worked on code bases which does
event loop spinning on deep call stacks it's a horror I wouldn't want
to impose on anyone.

>> One possible action here would be to disallow sync APIs in shared
>> workers for now. This way we can use dedicated workers as a test bed
>> to see if sync APIs are a problem, and if they are, if that problem
>> can be fixed.
>
> This will just make people proxy messages from the shared worker to a
> dedicated worker, so nothing would change.  I don't think making shared
> workers more different from dedicated workers than they have to be makes
> much sense.

"People can already do things the wrong way" is a terrible argument
for introducing more ways of doing it the wrong way. The same argument
could be used to say that we should add sync IO APIs on the main
thread. It's already the case that you can write pages whose UI
doesn't respond until you get a result back from a worker or an async
IO operation.

/ Jonas

Re: [HTML Imports]: Sync, async, -ish?

[Daniel Buchner]

Of course I realize this Jonas, but I assure you, if you burden the most
common use-cases with poor ergonomics, developers will find even more
ghastly ways to degrade perf. Can someone post an overview of the proposed
solutions, and how they apply to the use-cases stated a few posts back?


On Fri, Nov 22, 2013 at 9:05 AM, Jonas Sicking  wrote:

> On Nov 22, 2013 8:24 AM, "Daniel Buchner"  wrote:
> >
> > Personally I don't have any issues with this solution, it provides for
> the use-cases we face. Also, it isn't without precedent - you can opt for a
> sync XMLHttpRequest (not much different).
>
> Except that sync XHR is considered one of the great miss designs of the
> web and is causing huge UI issues for users and great pain for developers.
> If we had the opportunity we would remove it in a heartbeat.
>
> / Jonas
>

Re: [HTML Imports]: Sync, async, -ish?

[Daniel Buchner]

I'm not talking about the script blocking as usual - I'm referencing the
presence of a script causing the import to block until completed, when the
script follows it.


On Fri, Nov 22, 2013 at 8:57 AM, John J Barton
wrote:

>
>
>
> On Fri, Nov 22, 2013 at 8:22 AM, Daniel Buchner wrote:
>
>> Personally I don't have any issues with this solution, it provides for
>> the use-cases we face. Also, it isn't without precedent - you can opt for a
>> sync XMLHttpRequest (not much different).
>>
>> The best part of an explicit 'sync' attribute, is that we can now remove
>> the "block if a script comes after an import" condition, right Dimitri?
>>
> As far as I know, 

Re: [HTML Imports]: Sync, async, -ish?

[Jonas Sicking]

On Nov 22, 2013 8:24 AM, "Daniel Buchner"  wrote:
>
> Personally I don't have any issues with this solution, it provides for
the use-cases we face. Also, it isn't without precedent - you can opt for a
sync XMLHttpRequest (not much different).

Except that sync XHR is considered one of the great miss designs of the web
and is causing huge UI issues for users and great pain for developers. If
we had the opportunity we would remove it in a heartbeat.

/ Jonas

Re: [HTML Imports]: Sync, async, -ish?

[John J Barton]

On Fri, Nov 22, 2013 at 8:22 AM, Daniel Buchner  wrote:

> Personally I don't have any issues with this solution, it provides for the
> use-cases we face. Also, it isn't without precedent - you can opt for a
> sync XMLHttpRequest (not much different).
>
> The best part of an explicit 'sync' attribute, is that we can now remove
> the "block if a script comes after an import" condition, right Dimitri?
>
As far as I know, 

Re: [HTML Imports]: Sync, async, -ish?

[Daniel Buchner]

Personally I don't have any issues with this solution, it provides for the
use-cases we face. Also, it isn't without precedent - you can opt for a
sync XMLHttpRequest (not much different).

The best part of an explicit 'sync' attribute, is that we can now remove
the "block if a script comes after an import" condition, right Dimitri?

- Daniel
 On Nov 22, 2013 8:05 AM, "John J Barton" 
wrote:

> I agree that we should allow developers to set 'sync' attribute on 
> tags to block rendering until load. That will allow them to create sites
> that appear to load slowly rather than render their standard HTML/CSS.
>
> I think that the default should be the current solution and 'sync' should
> be opt-in. Developers may choose:
>1. Do nothing. The site looks fine when it renders before the
> components arrive.
>2. Add small static content fixes. The site looks fine after a few
> simple HTML / CSS adjustments.
>3. Add 'sync', the site flashes too much, let it block.
> This progression is the best for users.
>
> jjb
>
>
> On Thu, Nov 21, 2013 at 5:04 PM, Steve Souders  wrote:
>
>> DanielF: You would only list the custom tags that should be treated as
>> blocking. If *every* tag in Brick and Polymer should be blocking, then we
>> have a really big issue because right now they're NOT-blocking and there's
>> nothing in Web Components per se to specify a blocking behavior.
>>
>> JJB: Website owners aren't going to be happy with either situation:
>>   - If custom tags are async (backfilled) by default and the custom tag
>> is a critical part of the page, subjecting users to a page that suddenly
>> changes layout isn't good.
>>   - If custom tags (really HTML imports) are sync (block rendering) by
>> default, then users stare at a blank screen during slow downloads.
>>
>> I believe we need to pick the best default while also giving developers
>> the ability to choose what's best for them. Right now I don't see a way for
>> a developer to choose to have a custom element block rendering, as opposed
>> to be backfilled later. Do we think this is important? (I think so.) If so,
>> what's a good way to let web devs make custom elements block?
>>
>> -Steve
>>
>>
>>
>> On Thu, Nov 21, 2013 at 3:07 PM, John J Barton <
>> johnjbar...@johnjbarton.com> wrote:
>>
>>> Ok, so my 2 cents: it's ok but it gives a very Web 1.0 solution. We had
>>> to invent AJAX so developers could control the user experience in the face
>>> of significant network delay. As I said earlier, most apps will turn this
>>> problem over to the design team rather than cause users to leave while the
>>> browser spins waiting for the page to render.
>>>
>>>
>>> On Thu, Nov 21, 2013 at 3:01 PM, Daniel Buchner wrote:
>>>
 Yes, that's the primary motivation. Getting FUC'd is going to be a
 non-starter for serious app developers. We were just thinking of ways to
 satisfy the use-case without undue burden.

>>>
>>>
>>
>

Re: [HTML Imports]: Sync, async, -ish?

[John J Barton]

I agree that we should allow developers to set 'sync' attribute on 
tags to block rendering until load. That will allow them to create sites
that appear to load slowly rather than render their standard HTML/CSS.

I think that the default should be the current solution and 'sync' should
be opt-in. Developers may choose:
   1. Do nothing. The site looks fine when it renders before the components
arrive.
   2. Add small static content fixes. The site looks fine after a few
simple HTML / CSS adjustments.
   3. Add 'sync', the site flashes too much, let it block.
This progression is the best for users.

jjb


On Thu, Nov 21, 2013 at 5:04 PM, Steve Souders  wrote:

> DanielF: You would only list the custom tags that should be treated as
> blocking. If *every* tag in Brick and Polymer should be blocking, then we
> have a really big issue because right now they're NOT-blocking and there's
> nothing in Web Components per se to specify a blocking behavior.
>
> JJB: Website owners aren't going to be happy with either situation:
>   - If custom tags are async (backfilled) by default and the custom tag is
> a critical part of the page, subjecting users to a page that suddenly
> changes layout isn't good.
>   - If custom tags (really HTML imports) are sync (block rendering) by
> default, then users stare at a blank screen during slow downloads.
>
> I believe we need to pick the best default while also giving developers
> the ability to choose what's best for them. Right now I don't see a way for
> a developer to choose to have a custom element block rendering, as opposed
> to be backfilled later. Do we think this is important? (I think so.) If so,
> what's a good way to let web devs make custom elements block?
>
> -Steve
>
>
>
> On Thu, Nov 21, 2013 at 3:07 PM, John J Barton <
> johnjbar...@johnjbarton.com> wrote:
>
>> Ok, so my 2 cents: it's ok but it gives a very Web 1.0 solution. We had
>> to invent AJAX so developers could control the user experience in the face
>> of significant network delay. As I said earlier, most apps will turn this
>> problem over to the design team rather than cause users to leave while the
>> browser spins waiting for the page to render.
>>
>>
>> On Thu, Nov 21, 2013 at 3:01 PM, Daniel Buchner wrote:
>>
>>> Yes, that's the primary motivation. Getting FUC'd is going to be a
>>> non-starter for serious app developers. We were just thinking of ways to
>>> satisfy the use-case without undue burden.
>>>
>>
>>
>

Re: Sync IO APIs in Shared Workers

[Glenn Maynard]

On Thu, Nov 21, 2013 at 8:33 PM, Jonas Sicking  wrote:

> One of the arguments made against sync APIs in workers made in [1] is
> that even for workers, it is often important to keep code responsive
> in order to react to actions taken by the user.
>

The only relevant thing I can dig out of [1] can be summarized much more
simply: "we need a way to interrupt synchronous calls".

It'd be tricky to allow interruption while still leading to robust code,
but I think it's worth exploring.  In principle it violates the "don't
expose asynchronous behavior" principle, but in reality, asynchronous
programming with messages coming from other threads does the same thing.
We'd need to make sure it's very clear which calls can be interrupted, to
avoid EINTR-like problems.

But, we should explore the use cases more thoroughly first, to see if this
is really needed.  An alternative is to just terminate() the whole worker
and start a new one.  That's not very elegant, but it's very simple and
robust: you don't end up with synchronous APIs throwing exceptions
unexpectedly and worker code having to clean up after it.  If the work is
expensive enough that you need to cancel it, the cost of spinning up a new
worker is negligible.  Are there use cases where this doesn't work?

I.e. while locking up a worker thread for an extended period of time
> won't cause problems like stuttered scrolling or UI that doesn't
> visually react when you click them, you can still end up with apps
> that seem unresponsive since the main thread is waiting to get back an
> answer from a worker thread that is busy.
>

(This isn't an argument against sync APIs.  The same thing will happen with
async APIs if the page fails to give appropriate feedback to the user.)


> I also don't buy the argument that we can make async programming so
> convenient that there's little cost to async APIs compared to sync
> APIs.


I think it's wishful thinking.  My experience is that async programming is
inherently less convenient than sync programming.

Another solution would be to use real sync IO APIs, but expose an
>
object in the parent thread which allows the parent to abort the
> current operation.
>

(I'd use a MessagePort, eg. setCancellationPort(port), since the parent
thread shouldn't be special.)


> Something else that could improve responsiveness while still allowing
> people to write synchronous code is the ability to check if there are
> pending messages on a channel without having to return to the event
> loop. That way the code can keep running until there's a message to
> process, and only return to the event loop when there is.
>

http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1075.html
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0967.html

The proposal is to allow polling a MessagePort, retrieving the next message
without having to return to the event loop.  I think that's useful to allow
number crunching workers to periodically check for new information, without
having to return all the way to the event loop.  It never got traction,
though.

One possible action here would be to disallow sync APIs in shared
> workers for now. This way we can use dedicated workers as a test bed
> to see if sync APIs are a problem, and if they are, if that problem
> can be fixed.
>

This will just make people proxy messages from the shared worker to a
dedicated worker, so nothing would change.  I don't think making shared
workers more different from dedicated workers than they have to be makes
much sense.

-- 
Glenn Maynard

Re: CfC: publish Candidate Recommendation of File API; deadline November 28

[Charles McCathie Nevile]

On Thu, 21 Nov 2013 19:44:29 +0100, Arthur Barstow   
wrote:



Hi All,

Arun completed processing the comments [Comments] for the Last Call  
version of File API [LCWD]. Although the comments resulted in changes to  
the spec (see [Diff]), no new features were added and the changes are  
considered bug fixes. The most significant change is the Constructor  
APIs in Section 7 - see [Section-7].


Arun proposes the spec be advanced to Candidate Recommendation and this  
is a Call for Consensus (CfC) to publish a CR  using the following  
version as the basis:


   


Please do.

...

I propose 3 months as the minimal amount of time before we are ready to  
advance the spec to Propose Recommendation  and I propose we re-use the  
CR exit criteria we used for the IDB CR:


[[
During the Candidate Recommendation period, which ends @T+3months, the  
WG will complete its test suite. Before this specification exits  
Candidate Recommendation, two or more independent implementations must  
pass each test, although no single implementation must pass each test.


I suggest s/each/every/ here just to disambiguate a bit more. But I can  
live with these as criteria.


cheers

chaals

--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com

Reminder: RfC: LCWD of Pointer Lock; deadline November 28

[Arthur Barstow]

 Original Message 
Subject:RfC: LCWD of Pointer Lock; deadline November 28
Resent-Date:Thu, 31 Oct 2013 19:36:52 +
Resent-From:
Date:   Thu, 31 Oct 2013 15:32:49 -0400
From:   ext Arthur Barstow 
To: public-webapps 



This is a Request for Comments for the Last Call Working Draft of
Pointer Lock:

  

If you have any comments, please send them to public-webapps @ w3.org by
November 28 using a Subject: header of "[pointerlock]".

-Thanks, AB

Re: Sync IO APIs in Shared Workers

[Simon Pieters]

On Fri, 22 Nov 2013 03:33:51 +0100, Jonas Sicking  wrote:


The only browser shipping SharedWorkers is Chrome (not sure if Opera
does too?),


Yes, both Presto-based (since Opera 10.60) and Chromium-based.

--
Simon Pieters
Opera Software