[Asterisk-Dev] PyGTK Asterisk UI

[Steven Sokol]

Jim,

I just read your response to my response.  Interesting.  You obviously have
a lot of experience in OO design.  I have a few questions and ponderings.
Please let me know what you think....

How do you envision this administration framework "attaching" to Asterisk?
In scanning the mailing list, I have seen a number of postings in which
people suggest re-writing Asterisk (or important chunks of it) using OO
methods and tools.  In each case, the community seems to react negatively,
primarily because Asterisk is as close to a real-time application as you can
get in a non-real-time environment.  Most seem to feel that, generally
speaking, OO languages add too much overhead.

Personally, I have no idea.  I haven't ever written anything that is truly
real-time, or even near real time, until I got into this IAX Phone project.
I just wonder where the admin framework would "attach" to the existing code
(or if it would attach directly).  Part of it may depend on the way the
switch operates.

It would appear that the switch loads the .conf files at startup and
thereafter only re-loads them (most of them, at least) when the reload
command is executed.  This would indicate that most configuration
information is loaded into memory and is stored in some format (a set of
arrays of structures, or a list of structures, or a hash table or some damn
thing...).  This would indicate that, in order to implement on-the-fly
changes, we would have to build an API to access those buffered
configuration structures.  (I'm talking out of my hat here -- I really need
to RTFC before I go any further in.)

 From your description, it sounds like the interface would attempt to update
the running configuration before updating the persistent copy of the
configuration.  Again, from the hat, but that sounds like it would take
changes to _each_and_every_ channel, application and resource in Asterisk.
Very, very non-trivial.

I wonder if a phased approach wouldn't work.  The first phase would provide
a means of updating only the most commonly altered portions of the
configuration - extensions, and perhaps chan_sip and chan_iax2?  All other
changes can be made to the persistent cache which then feeds the switch
during a reload call.  Later phases could add live-change functionality to
additional portions of the codebase.

Markster, how do you feel about this?  Anybody else have thoughts?

Regards,

Steven 

Steven Sokol
Owner/Manager
Sokol & Associates, LLC

Phone:  816.822.1807
IaxTel: 700.613.9004
Web:    http://www.sokol-associates.com