Oh! And One more thing!
There needs to be an externally-facing way to call function/application
validators for those of us who write dynamic dialplan generators. Maybe
an AMI command?
Action: ValidateFunction
Function: MAX
Param[0]: foobar
Response: Error
Message: All inputs must be integer
Action: ValidateApplication
Application: Goto
Strict: false <-- allow for generic 'does it look okay' testing vs
does the destination actually exist
Param[0]: foo
Param[1]: bar
Param[2]: 1234
Response: Success
Warning: Destination context 'foo', extension 'bar', priority 1234 does
not exist
Action: ValidateApplication
Application: Goto
Strict: true
Param[0]: foo
Param[1]: bar
Param[2]: 1234
Response: Error
Message: Destination context 'foo', extension 'bar', priority 1234 does
not exist
And then more of a full validator via a new application and AMI Command
ValidateDialplanFile(/tmp/new_extensions.conf,/tmp/path_to_errors.log);
^--- Sets DIALPLAN_VALID = 1/0
Action: ValidateDialplanFile
File: /tmp/new_extensions.conf
Log: /tmp/path_to_errors.log
Response: Success
And, direct response via AMI
Action: ValidateDialplanFile
File: /tmp/new_extensions.conf
Response: Error
EventList: start
Message: Errors/Warnings will follow
....etc etc
On 1/5/22 18:06, Mark Murawski wrote:
Hi!
Throwing my .02 in here. Adjust to .10 for inflation!
On 1/4/22 14:53, aster...@phreaknet.org wrote:
.... However, there are a lot of dialplan problems that represent
potentially valid syntax that will cause an error at runtime, such as
branching to somewhere that doesn't exist. The dialplan will reload
with no errors, since there isn't a syntax issue, but at runtime, the
call will fail (and most likely crash). I found over the years that a
lot of these were often simple typos or issues that were easily fixed
but wasted a lot of time in finding solely in the "test, test, test"
approach. Another common grievance I hear time to time about the
dialplan is most issues are caught at runtime, not "compile time"
(i.e. dialplan reload).
I love it!
And... take an example from a basic cli call that has a validator built-in:
static char *meetme_kick_cmd(struct ast_cli_entry *e, int cmd, struct
ast_cli_args *a)
{
switch (cmd) {
case CLI_INIT:
e->command = "meetme kick";
e->usage =
"Usage: meetme kick <confno> all|<userno>\n"
" Kick a conference or a user in a
conference.\n";
return NULL;
case CLI_GENERATE:
return complete_meetmecmd_mute_kick(a->line, a->word,
a->pos, a->n);
}
if (a->argc != 4) {
return CLI_SHOWUSAGE;
}
return meetme_cmd_helper(a);
}
This design pattern has self-contained validation. And it's up to the
function to validate as much or as little as it wants to.
We would need a new ast_register_application_xml2 and
ast_custom_function_register2 to have a new design pattern for
self-validating functions and applications.
Each application would know what kind of parameters it takes, and what's
valid and not valid
new-stle for say... Goto Application
static int gosub_exec(int cmd, struct ast_channel *chan, const char *data)
{
if (cmd == APP_PARAMS_VALIDATE)
... do some validation!
ideally gosub knows it's being passed an exten/context/priority and can
call ast_exists_extension at dialplan parse time via the validator flow
This would be a major undertaking to add validation for every function
and every application but since dialplan is so ubiquitous and is
probably never going away... would make huge inroads to making sure
everything is as correct as possible at parse/load time.
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
