Andrei Pelinescu-Onciul wrote:
> General requirements:
>
> - ? exception support (under discussion)?
I think we should also clearly state the scope, i.e., what circumstances
are actually supposed to raise an exception. There are all kinds of
"failures": failed routing logic (no route, user-location lookup hasn't
yielded a contact) , server error (no memory), failed external
interaction (database, DNS), failed network operation (no route found
for forwarding), failed transaction processing (timeout).
Also in this context, if we do it, it could be meaningful to change
failure_route and such to be exceptions.
> - functions should return a value (e.g.: $val=find_re("^P-NAT:[ \t]*(.*)$);)
Absolutely.
> - functions should take variables as parameters by default
> (no special rewrite for avp/variable support should be needed, all
> functions should have it)
This one apears very important to me too.
> - faster and more compact (less memory) avps
I think AVPs should be referred to by (and only by) names, or actualy
"handles" to those. (no more reference by magic integers, or by names,
or most horribly either). Faster means abandoning linear lists.
> 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?
An unsolicited answer: I think that if we shall have different scopes,
lifetimes, types of vars, etc, we shall have advance declaration of
those. That shall not conflict with DB-defined AVPs; i should be actualy
fine as these defined externally are likely to be used externally too
(and not within a script).
-jiri
_______________________________________________
Serdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/serdev
