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
