Re: Processing Model

Replies inline.

On Fri, Oct 2, 2015 at 9:20 PM, Joe Berkovitz <joe@noteflight.com> wrote:

> [chair hat off]
>
> Hi Paul,
>
> I'm beginning to review your changes and wanted to start with  the
> processing model. I think it's an really important section and I'm glad you
> made this. I think the concepts make sense.
>
> Leaving wordsmithing aside for later, I have a couple of observations:
>
> - There is some confusion/conflation between "messages" and "operations"
> and "methods". In 3.3 you say, "calling methods on nodes must be done in
> two phases, sync and async". Then you proceed to talk about how the sync
> and async part of operations (not methods) are ordered. And later you talk
> about the "asynchronous section of a message" in 3.4.
>

> I think it's necessary to explain this by connecting the terms more
> explicitly. Methods invoke operations. The sync part of an operation then
> executes immediately; following that (if successful), a control message
> encodes the async part of the operation and is enqueued, to be picked up by
> a rendering thread.... IIRC.
>
> I have a feeling that it will be useful to sometimes define operations
> separately from methods.
>

It is indeed for some things. For example, there is an operation when you
create an AudioContext that ends up sending a "statechange" event, but no
methods have been called.


>
> - There is a reference to multiple rendering threads, but I don't think
> this algorithm takes advantage of them since it always processes all nodes
> in the graph. That's fine but needs to be called out somehow until we
> define the spec in a way that supports subgraphs served by different
> threads.
>

This mostly means you can implement it with multiple threads, but it's not
very useful. I'll probably remove it for now.


>
> - It feels as though the cycle detection piece of 3.4 would be well served
> by being algorithmically described at the same level of detail as the node
> ordering. Also, I don't know if the concept of "belonging to a cycle" is
> automatically clear. What if a node is on a dead-end chain that branches
> away from a cycle, but it not directly included in the cycle's path?
>

This needs work indeed, it's just a first pass. As said, there are edge
cases.

Paul.


>
> --
> .            .       .    .  . ...Joe
>
> *Joe Berkovitz*
> President
>
> *Noteflight LLC*
> 49R Day Street / Somerville, MA 02144 / USA
> phone: +1 978 314 6271
> www.noteflight.com
> "Your music, everywhere"
>