[asterisk-dev] Arbitrary hangup handlers [patch]

[Tilghman Lesher]

(Please email to the list in plaintext format.  HTML is both wasteful and it
can be leveraged to spread malware.  As an old friend of mine put it, "Do
you want me to force you to see porn?")

On Tuesday 14 September 2010 16:44:56 Mark Murawski wrote:
> On 09/14/2010 12:08 AM, Tilghman Lesher wrote:
> > On Monday 13 September 2010 15:55:50 Mark Murawski wrote:
> > > I've just finished writing a hangup handler module. And associated
> > > helper function ast_pbx_exten_parse(), which I think is needed to
> > > separate the functionality of parsing a gosub target from actually
> > > going to the target.  It's been malloc debugged and valgrind debugged.
> > >
> > > Overview of module:
> > > I find the 'h' extensions to be limited, cumbersome, and error prone
> > > when writing very complex dialplan, especially when using lots of gotos
> > > and gosubs.  Say you have a main dialplan entry point context called
> > > callqueue.  If at any point after callqueue runs, you want to run a
> > > hangup handler specific for the callqueue dialplan, you have to put an
> > > 'h' extension in every single context you plan to possibly jump to
> > > after entering callqueue.  This solves that problem, and gives the
> > > added benefit of cascading hangup handlers.
> >
> > I'd like to see mechanisms both for adding and removing handlers,
> > especially if you're going to have multiple handlers, in no particular
> > order (or reverse order, if this is a stack).  We absolutely need to
> > define what particular order each will run, if we have multiple, and
> > reverse order is likely the most practical.
> >
> > Perhaps, on the order of:
> > Set(CHANNEL(hanguphandler,add)=somesubroutine,h,1)
> > Set(CHANNEL(hanguphandler,remove)=somesubroutine,h,1)
> > and one that pops the last off and adds a new one in a single step:
> > Set(CHANNEL(hanguphandler,replace)=nextcheckpoint,h,1)
>
> Looks good.  I'll add the remove/replace.
>
> I'm always a fan of maximal introspection.  What about functions that
> inspect the hangup handler list?
>
> What's the preferred format for getting multi part data via functions?
> There's functions like CHANNELS(), which return a space delimited list. 
> Personally I don't like plaintext delimited lists when you can avoid them,
> because no matter what delimiter you use, someone is going to want to use
> that delimiter as part of their data.
>
> Before CHANNELS() was available, I wrote my own channels listing function
> which functions like
> Set(count=${GET_CHANNELS_LIST(foo.*)}); 
> while i < count
>   Set(nextchan=${GET_CHANNELS_LIST_NEXT()});
>
> So now you have access to each exact channel name with no delimiters and
> no CUT()/etc required
>
> So with that in mind, I'm thinking something like:
>
> Set(count=${CHANNEL(hanguphandler,list)});
> Set(handler=${CHANNEL(hanguphandler,list_next)});

There is no need to iterate, only a need to be able to retrieve the number of
items in the list and a way to access each item in the list, in turn.
${CHANNEL(hanguphandler,count)}  ; Number of items
${CHANNEL(hanguphandler,list)}  ; The whole list, in space-delimited format
${CHANNEL(hanguphandler,0)}    ; The first item in the list
${CHANNEL(hanguphandler,-1)}   ; The last item in the list
; Also the last item in the list
${CHANNEL(hanguphandler,$[${CHANNEL(hanguphandler,count)} - 1])}

-- 
Tilghman Lesher
Digium, Inc. | Senior Software Developer
twitter: Corydon76 | IRC: Corydon76-dig (Freenode)
Check us out at: www.digium.com & www.asterisk.org