Thank you Keith for describing the resource messaging requirements an suggested approach. This is not a major change to the structure of the flowgraph mechanizm, but it has a big impact on the amount of flexablity that we gain in how we can arrange the resources in a flowgraph.
There is a messaging system in there now for message to resouces and flowgraphs. Can you describe what is required that is not there today or what the problems of the existing message are. A few comments below. Thanks, Dan --- Keith Kyzivat <[EMAIL PROTECTED]> wrote: > Hello all, > > I'm heading up changing the resource messaging to work with a new > flexible > flowgraph topology that we're working on. > > As has been stated by Alex and Dan previously, our new vision of how > the > media library will work is that resources will just be resources, > addressed > by name and not pointer, and connected in many different > configurations. > Input and output are also updated for this new design, allowing for > variable > numbers of input and output devices. > > Due to this, the current method for sending and requesting messages > from > resources needs to change. > With the current implementation, each Flowgraph holds specific typed > pointers to each resource it holds. When one wishes to send a > message to a > resource, > they ask the flowgraph for the pointer to the specifically typed > resource > they wish to send to, then call the method for the message they wish > to > send. (Minor correction: MpCallFlowgraph has specific typed pointers to resource, it base class MpFlowgraphBase is clean treating the resources generically.) > > In the new view of the world, this will be more flexible, - no longer > holding specific resource pointers, and instead holding a hashmap of > resource names to generic Resource pointers (which already exists). The intention here is to realize this in the new flowgraph type MpTopologyGraph. MpCallFlowgraph will have minimal changes and will continue to have type specific resource pointers. At some point in which MpTopologyGraph provide more capabilities than MpCallFlowgraph, MpCallFlowgraph may be removed. > What we propose to do is to put the messaging methods as static > methods on > the specific resources that know about the message. Each of these > static > methods would take as parameters the OsMsgQ& queue to add the message > to, a > UtlString& resource name indicating the resource that this message is > to be > ultimately received and processed by, and any arguments that the > operation > needs to take. > For example: > > > MprBridge::setMatrix(OsMsgQ&, UtlString& bridgeName, int > mixVectorLength, > > int mixVectorWeights[], ...) > > > The reason for a queue as a parameter is that one may wish to send > the > message to the resource to the flowgraph, to the resource itself, or > to the > MpMediaInterface (specifying a flowgraph - since there's the > possibility > that the interface can contain more than one flowgraph). > > Referring to things by name and not by pointer is safer, and allows > for more > of the internals to be hidden from the outside. > > Any initial comments, questions? > > I'll be adding to this as things progress, and would be happy to > expand on > any explanations that might be non-obvious. > > Thanks! > > -- > Keith Kyzivat > > SIPez LLC. > SIP VoIP, IM and Presence Consulting > http://www.SIPez.com > tel: +1 (617) 273-4000 > _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
