Re: Resolution to republish MSP as a note

You are not the only one Jussi. I have been following this discussion with
great interest and I think the points you raise are fundamental in creating
a proper future-proof standard and merit very careful consideration.
Whatever we decide developers will likely have to live with for a very long
time. I personally only supported the move to the Web Audio API if we could
also include low-level features. I perhaps naively assumed a blend of low
and high level could work and this is why I was very happy to see the MSP
included as a note and hopefully provide inspiration for the low level
features.

It's true that right now JavaScript may not be capable of implementing some
other the features that are currently provided natively. But WE MUST ENSURE
WE ARE CREATING A FUTURE-PROOF STANDARD and this means giving developers
access to low level functionality so that a whole range of solutions that
haven't yet be imagined can be developed. I'm not against including the
high-level features but not at the expense of the low-level.

I believe that the fact that the Web Audio API was seeing better industry
adoption is not sufficient criteria alone to pursue it as a de-facto
standard. We as a W3C group have the responsibility to look further ahead
than the current crop of early adopters.

Standards are not about vendors, they are about developers. Personally I
like the low-level WebGL standard and I can rest easy knowing that higher
level libraries like three.js will continue to be developed by developers
for years to come. This is a reactive and progressive model in my opinion
and one that will stand the test of time.

This is a crucial time for the Web Audio standard and I would encourage
everyone on the group to consider the issues being discussed in this thread
in as much detail as they can and contribute their thoughts. I feel very
strongly that we should not push forward without proper discussion.

There is a great piece published about Standards (and Sausages) published
by Bruce Lawson recently - I would urge everyone to read it :
http://the-pastry-box-project.net/bruce-lawson/2012-august-4/

Sincerely

Mark

On 9 August 2012 09:16, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>wrote:

> On Thu, Aug 9, 2012 at 6:21 AM, Wei, James <james.wei@intel.com> wrote:
>
>>  “****
>>
>> Hence I'd rather we try to get RT thread support for workers so that one
>> can just decide whether to use a real-time thread or not by choosing the
>> type of worker to use.****
>>
>> “****
>>
>> ** **
>>
>> I think we cannot depend on a feature that not ready or even not
>> mentioned for Web Worker. Web Worker is sure not perfect and many people
>> complain and want to improve it. but at this time, we need to live with the
>> current spec and implementation. ****
>>
>> ** **
>>
>> If in future, this feature not implemented for workers, what should we do?
>>
>
> React accordingly? We can't just go doing our own thing separately of all
> the other entities involved because we're too impatient to wait for the
> other entities response. Why are we trying to define a standard anyway if
> we don't give a crap about what the other entities think?
>
> Currently the native nodes are not much more than premature optimization.
> If that feature will not be implemented in the workers it probably means
> that it's not allowed in other parts of web either, so using it in native
> nodes is a no-go too. I think we seriously need better communication with
> the other groups, this is probably something we should've asked the other
> groups before even starting on the Web Audio API... If it turns out that
> high-priority thread workers are a no-go but it's OK for native nodes, we
> can add them later, no damage done.
>
> Anyway, I'm starting to feel like I'm fighting the windmills here. If I'm
> the only one who thinks this idea is good, it's probably not very
> constructive use of our time to argue about it.
>
> Cheers,
> Jussi
>