I'm in the midst of implementing new resource messaging architecture, and
now realize that there is a case where someone wishes to execute an
operation directly on a resource,
as opposed to posting through the queue.
The new approach for doing this through queues (doing thing safely through
names, and not direct pointers) involves:
Calling a static operation method on the specific resource, passing the name
of the resource which you wish to operate on, and a reference to a flowgraph
queue.
e.g.: MpResource::enable("speaker1", myFlowgraphQueue);
This creates the resource message, and posts it to the queue.
This approach requires a queue - and makes processing operations directly on
resources not possible.
The approach I was thinking of going with to allow processing resource
operations directly on the resources now is creating a new public method on
MpResource:
MpResource::handleMessages(const OsMsgQ& msgQueue);
that goes through each message, just assumes the messages are for itself,
and processes them.
The messages that are inserted into this queue are new MpResourceMsg
messages, which are similar to MpFlowGraphMsg, but instead of holding
MpResource*, message type+subtype, and some generic data, they hold the name
of the resource and the type+subtype, with operation data instead being
dealt with in subclasses.
This approach will lead to several copies of the message being created (one
when initially created, one when added to queue), but I think it's OK in
this case -- most messages should be done through the flowgraph anyway, and
not directly on the resource.
Is there a better approach?
--
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/
