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