[asterisk-dev] Unified Asterisk Interface

[Matthew Rubenstein]

> Um, one is a synchronous interface that is a child of the Asterisk
> process
> itself (AGI) and the other is an asynchronous interface that can be
> used
> from anywhere (AMI).  I don't see how you could possibly combine the
> two
> and get a coherent interface.

	I don't see why an AGI process can't open a connection to the AMI, so
the AGI interface is still available AND the AMI interface is available
for sending commands and receiving/filtering events. I'd like to see AGI
extended include that AMI interface, including "event callbacks"
registered when the AGI starts (or whenever), that are functions in the
AGI script. I'd also like to see an AGI bound to a specific channel
instance also able to get status/commands of other channels, or global
Asterisk status/commands, like you suggested in a later message in this
thread. But having a single interface that implements every command and
status means not having to keep two different AMI and AGI processes
synced when using each to do two parts of a single meaningful operation
straddling both current interfaces.

	If getting access to external scopes is implemented, it should have
permissions granted in the exposing external scope, like in the dialplan
or .confs , or possibly in the external channel's AGI opening its own
scope to specified "public" or "friend" instances. Probably the best
implementation would be a "permissions daemon" allowing requests from
AGIs to access other AGIs/global, which is compared to a DB of
permission enablers that scopes can set on themselves.


On Tue, 2007-12-11 at 10:43 -0600, asterisk-dev-request at lists.digium.com
wrote:
> Date: Tue, 11 Dec 2007 09:21:52 -0600
> From: Tilghman Lesher <tilghman at mail.jeffandtilghman.com>
> Subject: Re: [asterisk-dev] Unified Asterisk Interface
> To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
> Message-ID: <200712110921.52799.tilghman at mail.jeffandtilghman.com>
> Content-Type: text/plain;  charset="iso-8859-1"
> 
> On Tuesday 11 December 2007 08:02:37 David Roden wrote:
> > On Monday 10 December 2007 20:17:58 Jim Capp wrote:
> > > This makes sense, but it is a little scary.  I like the separation
> of
> > > AGI and AMI from Asterisk.
> >
> > And that separation makes sense. What does not make sense (IMHO) is
> that
> > there are two APIs that each allow you to access a certain subset of
> > Asterisk's features only and no API that can be used to utilize
> every
> > feature Asterisk has to offer. (Just to make sure: The kind of API
> I'm
> > talking about allows access to Asterisk's features without access to
> the
> > source code.)
> 
> Um, one is a synchronous interface that is a child of the Asterisk
> process
> itself (AGI) and the other is an asynchronous interface that can be
> used
> from anywhere (AMI).  I don't see how you could possibly combine the
> two
> and get a coherent interface.
> 
> > > It allows us to build things without encumbering the server
> itself.
> >
> > Right. Currently I have to add three different AGI calls to an
> Asterisk
> > dialplan for my application to work. This is something I would like
> to get
> > rid of, or cut down at least to the required minimum--which would be
> a
> > single line.
> 
> Well, if you're addicted to AGI, you're going to love 1.6, since we've
> joined
> the boundary between live and dead mode and allowed an AGI to make the
> transition.
> 
> -- 
> Tilghman
> 
-- 

(C) Matthew Rubenstein