This is a call for proposals for changes and features you would like to
see in the future in ser.cfg scripts.
There are a few changes that we need to make that would require rather
big script engine changes and IMHO it would be better if we would
re-write it at some point in the not-so-distant future, so if we are
very likely to do it anyway it's better to start thinking about new
features.
I think it's best if we have short script examples rather then long
formal proposals.
Once we collect enough (I would expect that this would take several
months) we could start discussing what to include and what not, try
generating a larger example script including all the stuff and see if we
don't have any conflicting proposals. IMHO it's more important to try to
collect proposals first and not going into very specific
discussion/flamewars at this stage.
I will start with Martin's exception proposal and some examples and
requirements derived from a private discussion between me, Miklos and Jiri.
General requirements:
- ? exception support (under discussion)?
- functions should return a value (e.g.: $val=find_re("^P-NAT:[ \t]*(.*)$);)
- no more functions side effects (e.g. a function sets some avp
internally instead of either returning a result or setting a variable
passed as parameter)
- ? possibility to pass references to vars as parameter to a function
(e.g. foo(&var)) ?
- very fast temporary (per script) vars
- variable number of parameters for modules functions (no limits)
- functions should take variables as parameters by default
(no special rewrite for avp/variable support should be needed, all
functions should have it)
- avps should have different lifetimes: by default they should live only
in the current script, to survive transactions (and maybe dialogs)
they should be marked in a special way.
Not strictly script related requirements:
- the script engine/core should support old modules (with current
module interface) and updated modules in the same time
(in fact it should be possible for a module to have old style functions
and new style functions in the same time, to ease migration)
- faster and more compact (less memory) avps
- a way to describe function parameters, if they need fixup, if they
can be called without a fixup and maybe fixups that can be called at
runtime so that we can easily call functions from another modules or
even from external applications
- ?2 pass optimizations?
Questions:
- how would we distinguish tmp. vars from avps? (no '$' for vars,
something different, like '%' or do we change the way we refer to
avps)
- should we have vars with transaction lifetime (the line between them
and avps would become quite blurred)
- what scope should they have? block scope or global scope? global
scope by default and local if declared with something similar to
Perl's "my $var"?
- should all tmp. vars be declared at the script beginning (C like) or
we don't care (script like)?
- type conversions: script like or explicit?
Script examples:
$val=find_re("^P-NAT:[ \t]*(.*)$) ;
if (nonempty($val)) # or if ($?)
append_headers("P-Previous-NAT: yes", $header, "P-Y: no")
# no limit on the numbers of params
strip($how_many); # Jiri's favorite
(note: here $val is supposed to be a temp. var and not an avp,
one of the things to solve is what "notation" we will use for vars and
what for avps)
Andrei
P.S.: openser guys are also welcome, I didn't cross-post because I don't
know if they are interested
_______________________________________________
Serdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/serdev
