[asterisk-bugs] [Asterisk 0010635]: new function EXTSTATE() returns state of an extension

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10635 
====================================================================== 
Reported By:                adamgundy
Assigned To:                russell
====================================================================== 
Project:                    Asterisk
Issue ID:                   10635
Category:                   Functions/NewFeature
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.11  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             09-03-2007 19:37 CDT
Last Modified:              09-06-2007 00:10 CDT
====================================================================== 
Summary:                    new function EXTSTATE() returns state of an
extension
Description: 
the attached patch is based on the DEVSTATE() function, modified to return
the state of an extension, rather than a device. this means you can write
dialplan logic based on the state of an extension (in use, ringing, on hold
etc). the extension just needs to have a hint so we can determine which
devices to check.

any chance we can get this in 1.6 to go with DEVSTATE()?
====================================================================== 

---------------------------------------------------------------------- 
 Corydon76 - 09-06-07 00:10  
---------------------------------------------------------------------- 
While I'm not adamantly opposed to EXTSTATE(), I want to point out that its
implementation in the dialplan conflicts with the design philosophy behind
much of how the dialplan language was created.  That is, the pieces in the
dialplan should always reflect the most basic building blocks of proposed
needs, without crippling possible functionality.

We certainly could create many possible combinations using the basic
building blocks that we have created, but those prebuilt combinations would
only serve to clutter the dialplan and confuse new users as to which tools
they should use in constructing their dialplans.  I would invite a
comparison to the CISC versus RISC processors, whereby it was found that a
reduced set of instructions reduced clutter, simplified tasks, and made for
an all-around better processor.  The design philosphy seeks a similar end
for the dialplan language.

There are some notable exceptions to this philosophy in the dialplan, such
as Voicemail, but Voicemail is a legacy application which will get broken
down, both with the existing minivm implementation, as well as the
forthcoming ast_storage branch.  Directory is not quite as complicated as
Voicemail, but it, too, is being considered for replacement with smaller,
more fundamental building blocks.

So, as I pointed out earlier, the fundamental building blocks as I see
them are first, a HINT lookup, which finds the device hint for a particular
extension, and DEVSTATE, which determines a status for that found device. 
That is why I suggested the creation of the HINT() dialplan function.  I
hope this explanation makes it clearer as to why I gave you this
suggestion. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
09-06-07 00:10  Corydon76      Note Added: 0069992                          
======================================================================