[asterisk-dev] Another bounty - app_reload

[Matthew Rubenstein]

On Thu, 2006-10-05 at 12:00 -0700, asterisk-dev-request at lists.digium.com
wrote:
> Date: Thu, 5 Oct 2006 12:47:01 -0500 (CDT)
> From: "Kevin P. Fleming" <kpfleming at digium.com>
> Subject: Re: [asterisk-dev] Another bounty - app_reload
> To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
> Message-ID:
>         <11666049.10561160070421158.JavaMail.root at jupiler.digium.com>
> Content-Type: text/plain; charset=utf-8
> 
> ----- Matthew Rubenstein <email at mattruby.com> wrote:
> >       Actually, what seems missing from the diaplan apps is one that
> just
> > writes to the Manager API socket any passed string, and one to read
> > from
> > the Manager API socket any sent data.
> 
> There is no 'Manager API socket'. There can be many open sockets to
> Manager API users; how do you pick one?


	Sure there is a Manager API socket; there's the socket a client app
opens to the Manager API. Each client gets one that it makes; they all
go to the same process space and all return the same broadcast data, but
each client has to have its own socket to which it connects.


> How do you distinguish between Actions those AMI apps are requesting
> and the data that your app should read?

	I thought that's what the ActionID each action is tagged with is for.
That's how a client listener on the socket can tell that a reported
event is its own. A client could keep state when it sends an action,
then filter all received events for its list of sent ActionIDs. Or just
send actions with ActionIDs prefixed with its own unique client instance
ID, like FQDN+PID+startuptime. I wish the Manager could accept
registered clients and send back on their specific sockets only events
originating from them, so no filtering necessary (subscription instead
of broadcast), but then there would be a limit to cross-client state
communication without explicit messaging between clients, either P2P or
through some Asterisk channel. An API for clients subscribing to
multiple client channels and broadcast would be best, but I don't dare
to hope for such a messaging system when what we've got is so
rudimentary (and apparently basically effective).


> If there are 20 channels in the dialplan all doing these reads, how do
> you control which channel the data goes to?

	Actions sent to the Manager are already tagged with their context,
which seems to solve that problem.

	In fact, the Action specifications' inclusion of ActionID and contexts
seems designed for exactly for this kind of multiclient communication
with sockets all getting/receiving broadcast messages. Subscription is
just an optimization reducing redundancy and filtering in the clients.
And my syntax, ManagerSubscribe(<variable>), is syntactic sugar wrapping
periodic filtered reads of the buffered output from the socket
connection to the Manager.


> If you want to open a socket from the dialplan to an app and
> read/write it, then that would be something that would make logical
> sense (don't know how practical it would be though).

	That setup would allow a dialplan context to send clients to specified
clients, but just moves the filtering from the client to the dialplan.
Where it loses sync with commands sent from the client to the Manager,
correlated by ActionID. I'm not sure why you'd do that, but it certainly
is an option.


> -- 
> Kevin P. Fleming
> Senior Software Engineer
> Digium, Inc.
> 
-- 

(C) Matthew Rubenstein