Andrei Pelinescu-Onciul wrote:
>
> This is a call for proposals for changes and features you would like to
> see in the future in ser.cfg scripts.
Before I go into your points, here's what I have:
o Loops. While you can already loop recursively to a points, an
iterative loop would be nice.
o Includes or some sort of module mechanism. This is currently done
using M4 or CPP. Maybe we can have a native include mechanism.
Alternatively, SER can use a pre-processor such as CPP all by
itself.
o Functions instead of routes. Allow the definition of routes with
arguments and a return value and drop the distinction between
functions provided by the core or modules and what you define in
your script. Together with the include mechanism, this allows the
creation of libraries.
And, just to be bold:
o Drop the ser.cfg language and use Python as the script language.
> 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)
Don't go there. One of the really bad features of Perl is that it has
all special chars as prefixes for symbols.
How about this: There are only variables. However, we define a new
container type which holds what is now attributes. In the script, this
type is actually a reference. You cannot create them but only get them
from some function which takes care of creating them in such a way that
they get stored where necessary. For tm, that could look like so:
$t_attrs = transaction_attrs()
Internally, this type is a struct with a list of functions for accessing
the attributes. The internal representation of transaction_attrs() returns
that struct.
In the script, you access them like you currently do with the prefixes,
eg.,
$tm.fr_inv_timer = 3000;
If we do this, we should probably merge the current database stuff into
this.
$from_uri = @ruri;
$from_did = lookup_domain($from_uri);
$from_uid = lookup_user($from_uri);
# ...
$from_attrs = db_attrs();
load_domain_attrs($from_attrs, $from_did);
load_user_attrs($from_attrs, $from_uid);
load_uri_attrs($from_attrs, $from_uri);
I don't think we need to keep the distinction of $fd, $fu, and $fr any
more in these cases. load_*_attrs() just simply overides any existing
attribute.
If you want to keep some attributes for the transaction, you have to
copy them manually:
$tm.fr_inv_time = $to_attrs.fr_inv_timer.
Or, there could be a function that copies all:
copy_attrs($tm, $to_attrs);
The first way is better, since you only store with the transaction what
you actually need.
> - 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"?
The opposite (when designing a language rather get inspired by Python
then by Perl ;). If we turn routes into functions, we should probably
also have local variables which should be the default scope. For
globals we can reuse the above attributes mechanism. A module could
provide an attribute container that gets dropped at the end of script
processing:
route is_ruri_changed($ruri)
{
$globals = get_globals();
return $ruri = $globals.ruri;
}
(Well, I had to come up with some example that at least remotely made
sense.)
> - should all tmp. vars be declared at the script beginning (C like) or
> we don't care (script like)?
I'd prefer the latter. Also, the type should be determined magically
through any assignment.
> - type conversions: script like or explicit?
And here I'd go for explicit. Rational: Look at C++' implicit conversion
rules.
Regards,
Martin
_______________________________________________
Serdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/serdev
