[Asterisk-Users] Some (lack of) answers regarding the wakeup call application...
robf at geekthing.com
Tue Jun 1 08:27:09 MST 2004
Since I only seem to get questions, and no feedback, from the Wiki page,
I'll ask here. There seems to be no lack of opinions here...
I have a working wakeup call system on my home * system. The architecture
is something I'm not perfectly happy with, though. There are two AGI
scripts, written in Perl, which handle (a) scheduling, confirming,
and cancelling a wakeup call, and (b) the wakeup call itself, with the
option to snooze for 5, 15, or 30 minutes.
The Perl scripts use the Asterisk::AGI module I came across months ago,
but by necessity, can't use the Asterisk/Perl code for creating call files
-- it has a habit of creating them right in the outgoing call queue,
generating a call immediately. So the Perl code creates call files in
a wakeup queue directory, and a cron job (a shell script) runs every
minute looking for wakeup calls in the queue that need to be handled,
and moves them to the outgoing call queue.
It has occurred to me that the two AGI scripts could be rewritten as real
compiled asterisk applications, but then it always hits me that without
some kind of cron-line built-in scheduler, or changes to the outgoing
call queueing that would allow a call to be scheduled for the future,
there would still be that external cron-driven shell script. Ugly.
What I'm wondering is this: Is there enough interest in the new features
I mentioned (either an internal scheduler or scheduled outgoing calls)
that I should work on a C version of the wakeup AGI scripts, or should
my (impending) next rewrite maintain the current architecture?
Anyone with specific questions about using my wakeup app, please email
Rob Fugina, Systems Guy
robf at geekthing.com -- http://www.geekthing.com
My firewall filters MS Office attachments.
The superior pilot uses his superior talent and superior judgment to avoid
getting into situations where he needs to use his superior skill.
More information about the asterisk-users