[Clam-devel] Designing Network Composition

Natanael Olaiz nolaiz at gmail.com
Thu Jun 19 02:59:27 PDT 2008


I pasted some relevant aspects of your explanations from here and IRC on 
the discuss page of the GSoC project: 
http://www.clam.iua.upf.edu/wikis/clam/index.php/Talk:GSoC/Network_scalability_and_Blender_integration

El 06/16/2008 07:59 AM, Pau Arumí Albó escribió:
> Hi,
>
> I wanted to share same ideas about network scalability design and ask
> for feedback. 
> Having thought about it I think it will involve very large changes in
> the Network. Besides discussing design in the mailing list it would be
> worth to meet at irc, ideally Natanael, David and me. I'll try to be
> available during this week. Just ping me.
>
> Let's start with a rough proposal. Imagine this scenario of two very
> simple networks composed like this in NE:
>
>   parent network:
>
>               +-------- sub net ----------+ 
>     src --->  |  src --> filter1r--> sink | --->  filter2  ---> sink  
>               +---------------------------+
>
>
> 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.
>
> Note that I'm taking an approach of avoiding "proxy" objects that
> delegates connections by themselves (like the PortPublisher in compiled
> Composites). My experience with the Publisher solution is very bad (can
> expand on it later).
> I think that having a layer (in the Network class) that manages
> connections to composites (Networks) is a much simpler approach.
>
> Of course this have a great impact on how the NetworkClass stores its
> components. But I think we should discuss the general approach before
> the implementation.
>
> Now get the critics and feedback in!
>
> Pau
>
>
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
>
>   





More information about the clam-devel mailing list