Processing Model

[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.

- 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.

- 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?

-- 
.            .       .    .  . ...Joe

*Joe Berkovitz*
President

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