- From: Joe Berkovitz <joe@noteflight.com>
- Date: Fri, 29 Apr 2016 08:00:09 -0400
- To: Hongchan Choi <hongchan@google.com>
- Cc: Raymond Toy <rtoy@google.com>, Audio Working Group <public-audio@w3.org>
- Message-ID: <CA+ojG-b8aZkfEFQbPnFCz8631i=JZAT8cXcr=Wztd0_EvehCOg@mail.gmail.com>
Hi Hongchan, I'm very happy for you to keep the task -- I'm only agitating for it to happen, not to take it over (unless that's helpful somehow). I'm all for waiting for things to settle down, that seems like a good idea. I was not sure where things were left at the F2F but it sounds like this action item didn't change. A few opinions on the items you mentioned -- but only chair-hat-off opinions! -- follow: - Static resource loading: I've been sitting on this idea for a while, but > I am inclined to punt this to V2. > I think that that would be fine if we don't find a nice way to do it. > - AudioParam initialization: I think we're getting close on this one, but > I heard TC39 is planning to introduce 'static property' in class syntax, so > I want to check it out. > I'm a little unsure about static properties being the way to go here. One of the advantages of using a function to define params is that AudioParam descriptors could be accumulated across the inheritance chain by concatenating arrays, or some such. If class FooNodeProcessor (or whatever we're calling these things now) has a parameter "foo", then a subclass FooBarNodeProcessor might want to add a parameter "bar" to whatever its superclass is defining. - Multiple node definitions in a single file: this allows developers to use > a hacky way of inter-node communication by sharing an object. > I don't see how this can be disallowed at the same time that we allow nodes to share read-only data. ...Joe
Received on Friday, 29 April 2016 12:00:42 UTC