Re: [gamepad] Seeking status and plans

[Marcos Caceres]

Hi All, 
The Gamepad API was briefly discussed at the LXJS conference.

See:
http://www.youtube.com/watch?v=ekvaKmVfjtc&t=5m30s

It seems at least one developer is very unhappy with it. 

Have we received any other feedback from developers about it? Has any effort 
been made to reach out to other developers to get feedback? 
 
Kind regards,
Marcos 

-- 
Marcos Caceres


On Thursday, October 10, 2013 at 7:12 PM, Ted Mielczarek wrote:

> On 10/2/2013 12:31 PM, Arthur Barstow wrote:
> > Hi Ted, Scott,
> > 
> > If any of the data for the Gamepad spec in [PubStatus] is not
> > accurate, please provide corrections.
> > 
> > Also, if you have any new information re your plans for the spec -
> > last published 29-May-2012 - or the spec's status with respect to
> > being feature complete, implementation status, etc., please let us know.
> > 
> > -Thanks, ArtB
> > 
> > [PubStatus] 
> Hi Art,
> 
> Thanks for the nudge! My work on the spec (and the Firefox
> implementation) fell by the wayside for many months, but I found some
> time to work on my implementation recently. We (Mozilla) are shipping a
> very-close-to-spec implementation in Nightly builds, and it's available
> behind a preference in our current release (Firefox 24).
> 
> I'd actually like to ship our implementation in release soon, I just
> have a few minor implementation bugs (with significant impact) to fix as
> well as one possible breaking spec change[1]. With those in order I'd be
> pretty happy to ship. We'd be shipping unprefixed, as is our new policy.
> 
> It's my understanding that Google has been shipping a prefixed
> implementation that's also pretty close to the spec for some time now,
> but that Scott suffers from the same "Gamepad is not really my full-time
> job" problem that I do. He'd be more equipped to talk about this than I
> am, certainly.
> 
> In terms of feature-completeness I think the spec is basically done.
> Aside from that one breaking change I'd like to make I don't think
> there's anything else we want to address right now that couldn't be done
> in a future release of the spec. We've wanted to keep the scope small
> from the beginning and I think we did okay. It definitely needs some
> more work (mostly polishing of the text, fixing the existing bugs), but
> we could certainly get out a new WD with the most recent text.
> 
> -Ted
> 
> 1. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21388 

CfC: publish LCWD of Custom Elements; deadline October 21

[Arthur Barstow]

Dimitri and I did not notice any concerns to the request for pre-LC 
comments for Custom Elements [pre-LC] so this is a CfC to publish a LCWD 
of this spec using the following ED as the basis:




This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD. Note the Process 
Document states the following regarding the significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

Currently, there are 10 open bugs for this spec and they have all been 
marked as Resolved/Later [Bugs].


The proposed review period for this LC is 4 weeks. If anyone thinks the 
review period should be longer, please speak up.


If you have any comments or concerns about this CfC, please send them to 
public-webapps@w3.org by October 21 at the latest. Positive response is 
preferred and encouraged and silence will be considered as agreement 
with the proposal.


Assuming this CfC passes, if there are any specific groups (e.g. HTMLWG, 
TAG, I18N, WAI, Privacy IG, Security IG, etc.) we should ask to review 
the LCWD, please let me know.


-Thanks, AB

[pre-LC] 


[Bugs] 

Re: Sync API for workers

[James Greene]

Could we change the method name under discussion to `postMessageSync`
instead of `postSyncMessage`? I know they're not grammatically equivalent
but I've always found the *Sync suffixes used on pertinent Node.js APIs to
be much more intuitive than trying to guess which position within a string
of words it should take.

Not sure on prior art within the web platform.
On Oct 14, 2013 4:59 AM, "Jonas Sicking"  wrote:

> On Mon, Oct 14, 2013 at 2:33 AM, David Rajchenbach-Teller
>  wrote:
> > Let me introduce the first sketch of a variant. The general idea is to
> > add a |postSyncMessage|
> >
> > We extend DedicatedWorkerGlobalScope and MessageEvent as follows:
> >
> > interface DedicatedWorkerGlobalScope : WorkerGlobalScope {
> >   void postMessage(any message, optional sequence
> transfer);
> >   any postSyncMessage(any message, optional sequence
> > transfer);
> > };
> >
> > interface SyncMessageEvent : MessageEvent {
> >   void reply(optional any message, optional sequence
> > transfer);
> > };
>
> This API was suggested by Olli way up in this thread. It has a few
> downsides:
>
> 1. It only allows a single synchronous message channel. That means
> that if you have several libraries that all need synchronous
> communication with the parent they have to coordinate on some way to
> distinguish each others messages. The fact that Gecko hasn't had
> MessageChannel support has resulted in the same problem for
> asynchronous communication and that has been a big headache for
> developers.
> 2. It doesn't support "streaming" return values. I.e. you can't send
> multiple return values from a single postSyncMessage call.
> 3. It doesn't allow direct synchronous communication between a worker
> and the workers "grand parent". Everything single message has to be
> individually routed through the parent.
> 4. What happens if you have multiple eventlisteners in the parent and
> several of them call .reply()?
>
> I wouldn't say that all of these are killer issues. I do think the
> first one is though. And the other three are clearly downsides.
>
> All in all I think the added complexity in the later proposal is worth it.
>
> / Jonas
>
>

Re: Sync API for workers

[David Rajchenbach-Teller]

This meant to be a more limited and well-behaved variant.
However, as pointed out by Jonas, a very similar proposal has been
submitted and discussed long before I joined this list. So, please
disregard my proposal, it is an artifact of me not searching the
archives well enough.

Best regards,
 David

On 10/14/13 4:14 PM, Glenn Maynard wrote:
> On Mon, Oct 14, 2013 at 4:33 AM, David Rajchenbach-Teller
> mailto:dtel...@mozilla.com>> wrote:
> 
> Let me introduce the first sketch of a variant. The general idea is to
> add a |postSyncMessage|
> 
> 
> (I'm not sure what problems with the existing proposals this is trying
> to solve.)
> 
> -- 
> Glenn Maynard
> 


-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla

Re: Sync API for workers

[Glenn Maynard]

You snipped the comment about waitForMessage().  I think it should return
an Event, as if the message had been received from onmessage, not just the
received data.

On Sun, Oct 13, 2013 at 10:37 PM, Jonas Sicking  wrote:

> This is certainly an improvement over the previous proposal. However
> given that synchronous APIs of any type are quite controversial, I'd
> rather stick to a basic approach for now.
>

There's nothing controversial about synchronous APIs in workers.  Doing
work synchronously is the whole point.

The nice thing about your proposal is that it's strictly additive, so
> it's something we can add later if there's agreement that the problems
> it aims to solve are problems that need solving, and there's agreement
> that the proposal is the right way to solve them.
>

This will cause people to learn to structure their workers poorly, and to
create worker libraries based on that structure, with extra message
relaying infrastructure to work around this, and pollute people's
still-immature understanding of message ports.  We should do it right in
the first place.


On Mon, Oct 14, 2013 at 4:33 AM, David Rajchenbach-Teller <
dtel...@mozilla.com> wrote:

> Let me introduce the first sketch of a variant. The general idea is to
> add a |postSyncMessage|
>

(I'm not sure what problems with the existing proposals this is trying to
solve.)

-- 
Glenn Maynard

Re: Sync API for workers

[Jonas Sicking]

On Mon, Oct 14, 2013 at 2:33 AM, David Rajchenbach-Teller
 wrote:
> Let me introduce the first sketch of a variant. The general idea is to
> add a |postSyncMessage|
>
> We extend DedicatedWorkerGlobalScope and MessageEvent as follows:
>
> interface DedicatedWorkerGlobalScope : WorkerGlobalScope {
>   void postMessage(any message, optional sequence transfer);
>   any postSyncMessage(any message, optional sequence
> transfer);
> };
>
> interface SyncMessageEvent : MessageEvent {
>   void reply(optional any message, optional sequence
> transfer);
> };

This API was suggested by Olli way up in this thread. It has a few downsides:

1. It only allows a single synchronous message channel. That means
that if you have several libraries that all need synchronous
communication with the parent they have to coordinate on some way to
distinguish each others messages. The fact that Gecko hasn't had
MessageChannel support has resulted in the same problem for
asynchronous communication and that has been a big headache for
developers.
2. It doesn't support "streaming" return values. I.e. you can't send
multiple return values from a single postSyncMessage call.
3. It doesn't allow direct synchronous communication between a worker
and the workers "grand parent". Everything single message has to be
individually routed through the parent.
4. What happens if you have multiple eventlisteners in the parent and
several of them call .reply()?

I wouldn't say that all of these are killer issues. I do think the
first one is though. And the other three are clearly downsides.

All in all I think the added complexity in the later proposal is worth it.

/ Jonas

Re: Sync API for workers

[Alon Zakai]

- Original Message -
> From: "David Bruant" 
> To: "Jonas Sicking" 
> Cc: "public-webapps" , aza...@mozilla.com
> Sent: Sunday, October 13, 2013 1:36:22 PM
> Subject: Re: Sync API for workers
> 
> > * You could solve the use case of compile-to-JS for code that uses
> > sync APIs using yield. However it requires changing all functions into
> > generators, and all function calls into yield* statements.
>
> all? as is "all function in the application"? that sounds like a too
> violent constraint, especially if a small proportion of the code uses
> sync functions. Maybe only the functions that may call a sync function
> need to be changed to generators... oh... hmm... I don't know.
> Taking the liberty to cc Alon Zakai to ask for his expert opinion on
> this topics.
> 

Not sure about all the context here. In general, the idea of using yield or CPS 
to handle synchronous code has come up in emscripten, but no one has done work 
to implement it, so we don't have a concrete answer for how practical it would 
be. My guess however is that it would be not very practical, because large 
codebases can have sync code anywhere, and relying on static analysis to 
simplify that so it is mostly not a factor is very optimistic. CPS all the time 
would likely be too slow; yield all the time I am less clear on because I am 
not sure the implementations are mature enough to benchmark yet (and no 
implementation at all in IE and Safari last I heard) - we would need to ask JS 
engine devs on that.

- Alon

Re: Sync API for workers

[David Rajchenbach-Teller]

On 10/13/13 4:21 PM, James Greene wrote:
>> a) is necessary, but for b) it is sufficient for the sync thread to be
>> able to sleep until a condition/mutex/... is lifted
> 
> In other words, your clarification is completely true but my initial
> statement was written with regard to client-side JavaScript, which
> cannot sleep. As such, I believe my original assertions are still
> correct with regard to writing a sync wrapper in JS.

My apologies, I had obviously misunderstood your initial statement. I
was thinking of an extension of the Worker API and how to implement it
at little CPU/battery clost.

Cheers,
 David

-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla

Re: Sync API for workers

[David Rajchenbach-Teller]

Let me introduce the first sketch of a variant. The general idea is to
add a |postSyncMessage|

We extend DedicatedWorkerGlobalScope and MessageEvent as follows:

interface DedicatedWorkerGlobalScope : WorkerGlobalScope {
  void postMessage(any message, optional sequence transfer);
  any postSyncMessage(any message, optional sequence
transfer);
};

interface SyncMessageEvent : MessageEvent {
  void reply(optional any message, optional sequence
transfer);
};

The behavior of |postSyncMessage| is the following:
1. the sender worker sleeps and does not handle any |postMessage|
messages until it is awakened;
2. instead of the usual |MessageEvent|, the target's |onmessage|
receives as argument a |SyncMessageEvent| (call it |s|);
3. if |s.reply(x)| is called, the sender's |postSyncMessage| method
returns a copy of |x|, obtained with the usual algorithm;
5. if |s.reply()| has not called by the time the worker is either
garbage-collected or |terminate()| is called on its |MessagePort|, the
worker is killed as usual.

I have not attempted to detail the inner workings of the underlying
MessagePort, but I suspect that this is close to Jonas Sicking's proposal.

Cheers,
 David