[Asterisk-Dev] PyGTK Asterisk UI

[Jim Burnes]

On Thu, Feb 26, 2004 at 08:11:47PM -0600, Steven Sokol wrote:
> 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....
>

ok.
 
> 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.

Hmmm.  That depends where you are using them, which ones you use and how.
If you wanted to implement a frame work by which individual modules/objects
could be updated, that certainly is within realtime specs.  Even if you had
to put together an interface in C that just looked like an OO interface
you could still do it.  Heck, you could do it in C++ if you were careful.

It's important to realize that in most "realtime" systems, relatively small
portions of the code are bound to hard deadlines.  The IVR scripting is 
decidedly non-realtime.  Various communcations layers are very close to 
hard realtime as defined by my defense and medical programming friends.

> 
> 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.
>

Agreed.
 
> 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.)
>

Yes.  It depends how new software and scripts are integrated into the whole
Asterisk engine.  If there is a possibility of communicating with new 
modules/objects via an RPC mechanism then you just have to figure out 
whether you changed a setting in a modular subsystem (loosely coupled)
or within the older architecture (may be tightly or loosely coupled).

Like you said, without reading the code I don't know.  Use the force,
read the source.

> >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.

Yes, but this would only work on the new subsystems, not on the older
system.  I'd have to think about the transaction model to figure out 
how you would implement persistance.  It's a little like a cacheing
problem.  What is worse, persisting a state that makes the system puke or
only persisting it after you are sure it's an acceptable value?

In a system that reads its config file in one sweep from a file, that's
not a problem.  If the program finds a serious error it simply quits 
and you fix and try again.  If you persist a bad value in a subsystem/module
whatever then I suppose that component just tells you to go to hell 
and ignores the request.  Again, I'm just thinking out loud here.

But what if the value you handed it looked good and then crashed the
module.  If you already persisted the value, you can't restart the module
because it would crash again.  This means that the maintenance of state 
settings must be independent of chatting with the object.  

I've got to go back and read some of my textbooks and code that 
cover persistance.  It seems like some sort of synchronization mechanism
is in order.  Basically you would push the new state to a shadowed or
persistant image of the object on disk.  Then you tell the object
to synchronize with it and report if there was an error.
If the update didn't work, you back out the shadowed version to the
previous one, fix it, etc.  

In a way, its like were writing little XML config files that contain
the serialization of the object state rather than one big fat one for
the whole system.  In this system, how do we differentiate between a 
simple method invocation (a command to the object), and persisting an
initial object state?  I guess you would have to do that explicity.
So we would have a definite reload state and a simple command message.

Interesting.  Depending on the language the module is implemented in
and it's ability to chat with us, we could use everything from a simple
rewrite of the config file, to XSLT translation to something like
near realtime control with ORBit.

But my brain is beginning to overload a little....sizzzlee....

Man, and I thought I would just be writing a big, fat config file ;-)

> 
> 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.
>

Yes.  Exactly what I was thinking. 

Implement a clean interface to the system.  The first cut would maintain
a clean config file state, probably in XML.  To generate a config file
you pump it through XSLT translation straight into the native config
format.  Tell the system to reload. Cake.

The next phase would be to come up with a consistent API/Interface
definition so that new modules could talk to you via xml-rpc, SOAP,
ORBit, whatever.

And I'm spent...

jim