[Asterisk-Dev] PyGTK Asterisk UI

[Jim Burnes]

On Thu, Feb 26, 2004 at 01:01:01PM -0600, Steven Sokol wrote:
> > Hi,
> > 
> > I'm working on an Asterisk UI using PyGTK and Kiwi.  I'm not sure if I
> 
> Jim,
> 
> I have been toying with the idea of a UI for Asterisk for some time.  I have
> even gone to the point of mocking up an HTML UI.  The problem I see is that
> there is no real, common back-end interface for the UI to hook into.
>

Yes.
 
> The flexibility of Asterisk is a double-edged sword.  With enough
> determination and a bit of basic programming skill, you can make Asterisk do
> damn near anything.  Unfortunately, that flexibility comes at the price of
> ease of configuration.  And what is difficult for an intelligent user, is
> even _more_ difficult for a program.
>

Mostly.
 
> What would be nice is a framework for programmatic administration of
> Asterisk, and an associated API based on that framework.  The framework
> would take into consideration what tasks are common to (nearly) all Asterisk
> implementations, and what could be done to automate those tasks.
>

Agreed.  If Asterisk has a proper OO design, reconfiguring an object shouldnt
have any effect on the objects that depend on it.  Of course, we don't have
control over other programs so we might have to at least have some way for
other objects to register themselves with the object we are changing so they
can update their own tables.

The more I think about it, the more you would have to figure out how granular
your control would be.  The deeper you go, the more it depends on the other
scripts.  Probably the best way would be to setup some sort of dependency
tree.  If all the objects that interface with ours are smart, then we just 
push our changes.  If something dependent on us is non OO, then we recommend
a restart of the entire subsystem -- perhaps in the worst case all of *.

 
> The other question that comes up is, how/where do you save the
> configuration?  I would _love_ to see an extension to Asterisk to overlay
> (or replace?) the various .conf files with relational data entities (or even
> highly structured flat-file entities like XML files).  Ideally this would
> allow you to create and IAX2.conf _table_ and an extensions.conf table, etc.
> 

You would need two layers.  One controls all of the systems that only
understand .config files and then all the systems that follow the new
control interface.  Part of the back-end is some sort of logic that takes
a decent guess as to whether a specific change necessitates application
restart.

> 
> The interface entity would require certain fields (matching the current
> required and optional entries in the associated .conf file) but would allow
> you to create additional entries that can be used to assist in programmatic
> manipulation of the system.  In a perfect world the interface entity would
> be generic, allowing you to us MySQL, PostgreSQL, OpenODBC, or an LDAP
> directory as the underlying data source.

Hmmm.  From an efficiency standpoint I agree, although I think that the 
underlying storage mechanism is not as important as the way in which we
interface to it.  Ideally the actual database would be abstracted away and
any changes you make to the Asterisk settings would be pushed via xml-rpc 
and then the OO control interface would make those changes persistant as
long as they took.  

In other words, if I push a IVR menu setting into Asterisk, the back-end
tells the IVR subsystem to make the change.  If the IVR subsystem can 
respond immediately and agrees, the back-end makes the interface object
persistant.  This is relatively straightforward in Python.

I'm not suggesting this, but Zope would handle this by simply committing
the objects into ZODB or whatever is attached as its object database.
Since Zope is written in Python, the code would be similar.

> 
> The database interface would, of course, be optional, leaving the ascii
> .conf files as the default method of configuration.  I would think that
> putting a database in place of the Channel config files (iax2, iax1, sip,
> zap, etc.) would be fairly easy.

Probably.  Again, the real bitch is figuring out whether you need to restart
a module when you change something.

>  The real challenge is in the configuration
> of the extensions.  I suppose it might be easiest (or most flexible) to
> maintain an extensions.conf file that includes all of the feature code
> (entries other than standard user extensions and standard service extensions
> {i.e. trunks, VoIP providers/gateways, etc.}).  You could store all of the
> "standard" extensions and services in the database and, when changes are
> made, append the data-driven information to the standing text and render an
> extensions.conf.
>

It might be a good idea to come up with some sort of standard way for various
objects/functions/modules whatever to expose their interface.  This would 
certainly make sense for objects that accepted events from user configurable
interfaces.
 
> The only inflexibility here is the fact that, if you are running a phone
> company off of your iax.conf file, it might be prohibitively slow/cpu
> intensive to reload _every_ time a change is made.

Yes.  I'd have to take a little closer look at the code to see if some of
this functionality already existed in *.  Is it possible to force only
subsystems to reload rather than the whole enchilada?  If we could make it
so that only old-style code needed to reload then at least there would be a
migration path.

>  A provisioning window
> could obviate this, but it's still not the best answer.
> 
> How are IaxTel and NuFone, etc. handling this?
>

I don't know.  
 
> Thanks,
> 
> Steve
> 
> Steven Sokol
> Owner/Manager
> Sokol & Associates, LLC
> 
> Phone:  816.822.1807
> IaxTel: 700.613.9004
> Web:    http://www.sokol-associates.com
> 
> 
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev