Talk:GSoC/Network scalability and Blender integration

From Clam

Subnetworks implementation

Pau's proposal

My proposed solution is to maintain two representations or views:

1. Hierarchic Network Representation : the one that the user edits in
NE, and gets saved in XML:
       parent:   src --> sub net --> filter2 --> sink
       sub net:  src --> filter1 --> sink
2. Flat Network Representation : the one scheduled by the FlowControl
class
       src --> filter1 --> filter2 --> sink

2 would not be directly edited (by the Network api), only 1 would be.
And all changes in 1 would be synchronized to 2.

i think that three lists would be sufficient to hold the network: processings: (proc1, proc2, ...)
and port_connections: (proc1.out1, proc2.my input, ...) and control_connections (...).

the main design decision we have to take is: are connections to sub-networks "managed" or "physical"?
My propose is 1. in composites we have 2

for example, NE receives a addConnection request. it the connection to a sub-network? 
yes. then let's try to do the physical connection (check type compatibility) and if ok,
let's do both connections, the physical and the connection in the "representation" layer 
-- which is implemented with few lists

<parumi|home> some questions that are not clear to me right now:
<parumi|home> 1. in the representation layer we want just strings or processing pointers?
<parumi|home> 2. the network have associated FlowControl object and NetworkPlayer object.
<parumi|home> but now, this only make sense for "parent" networks not sub networks. how we deal with it?

<nolaiz> about 1... i think using strings you could describe a little more about the subnetworks topology
<nolaiz> i mean, instead using a pointer to the processings, you could call it subnetwork1.processingxxx
<nolaiz> i don't know if that could be good or not

<parumi|home> well yes, processings ids will need namespaces now, sure