On 3/21/07, Alexander Chemeris <[EMAIL PROTECTED]> wrote:
Hello,
On 3/21/07, Keith Kyzivat <[EMAIL PROTECTED]> wrote:
> 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).
I do not understand this design well, so I'll here is my questions:
Understandable -- this is an evolving thing - I wanted to get folks' input,
and fix anything that seems broken.
:)
Who is the owner of message queue, passed to this methods? I.e. who create
and delete it and who sink and process messagesfrom it? Am I correct that
flowgraph and MpMediaInterface have their own queues and they pass their
own queue to this static methods, while resources do not have one and
could
not be accessed only via pointer.
I was mistaken - Resources themselves do not have OsMsgQ, so once it gets
down to the flowgraph, messages are processed direct on the resources.
The owner of the queues in this approach would be either the new flowgraph
class (MpTopologyGraph I believe), Interfaces associated with the flowgraphs
(controlling them), and maybe even MediaInterfaceFactories... The messages
flow downward, towards their destination flowgraphs, and eventually
resources. Those flowgraphs, MediaInterfaces or MediaInterfaceFactories
would own and control the queues.
How flowgraph will bw selected when posting message to MpMediaInterface?
There would have to be some form of flowgraphID to specify the flowgraph.
Now, off-list, you were suggesting some static lookup of resource to be able
to send a message...
2:25:55 PM alexander.chemeris: hrrrrmm... I think static
MpResource::enable() could look like this:
OsStatus MpResource::enable(MpResourceId id)
{
MpResource *pResource = getResource(id);
pResource->enable();
}
getResource would have to query some static hashmap mapping resourceID to
Resource pointer.
Right?
Another thing of note: Dan is recommending that resourceIDs are scoped
per-flowgraph, so in order for this to work properly, you'd have to pass a
flowgraphID for it to work.
Now, this method does not involve queues, and you'd just be having a
resource processing a message without regard to what is in the queue. It
would get run immediately. I thought that we were trying to get away from
that, to give messages a chance to process in the queue...
To reiterate what dan brought up - The old flowgraph and resources will work
just as they did before -- we're working in parallel to build a new, more
flexible flowgraph (MpTopologyGraph).
--
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/
