Couple more quick questions.<br>
<br>
Events generated in response to an action contain a unique id but not
the associated action id.&nbsp; I take it this is because the action id
isn't available to whatever part of the code actually generated the
event?<br>
<br>
The main challenge I am having with this interface is matching up
events with the actions that generated them, primarily when calling
Originate.&nbsp; The best thing I have found so far is to look at each
action and it's events and find something that is known when the action
is called, and is also present in every event generated by that
action.&nbsp; <br>
<br>
Right now the proxy server has one main thread that reads responses
from asterisk, and a thread for each client that connects to the
proxy.&nbsp;&nbsp; The main server thread puts all event responses into
one queue, and all other responses into another queue (the state queue
and action queue).&nbsp; The action queue is presumably responses which
have an action id.<br>
<br>
Connecting as a client is done via a ruby module that provides methods
for particular actions.<br>
<br>
For actions where the response will contain an action id, the client
waits until the response is received or a timeout is reached.&nbsp; For
actions that generate events, the client connects, sends the action,
and then disconnects.&nbsp; <br>
<br>
The client can then use methods for searching the state queue for
events it's interested in, or a method which just gives it the contents
of the entire queue.&nbsp; The search method takes a hash and searches
for events in the state queue with matching key/value
pairs.&nbsp;&nbsp; Rather than do something like&nbsp; hardcode in
Channel as the&nbsp; key to determine events that match an Originate
action, I decided to leave it up to the user, with some notes on what
seems to work.<br>
<br>
If anyone has any thoughts or input on this structure please let me
know.&nbsp; I'll be releasing it under a BSD license once it get it
wrapped up.&nbsp; <br>
<br>
Chris<br>
<br>
<br>