Martin Hoffmann wrote: > 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. > > Two more things: URI as a attribute type with the same access options as > URI selects (eg., $foo.user) and lists as attribute type. > > While the former is nice to have, the latter is very important to me. > Currently, to call forward to a list of recipients, I put all of them > into one attribute, separated by comma and then have to run a route > recursively that tears that apart and append_branche()s them.
do you have to? IMO a current data model's feature (which some consider a bug) is the capability to have multiple same-named AVPs. (getting you an unsorted set of values) > A list > would be much better -- not so much from script side, though, but from > the provisioning side. Just pushing an extra row into the database is > much easier and more logical. > > If you think the URI attribute type with "sub-selects" a bit further, > you end up at an interesting generalization. Those sub-selects actually > are methods called on a select or the result of such a method call -- > just without arguments. A more traditional way to put this: > > @from.uri().host() or host(uri(@from)) :-) the previous three characters not being part of the expression.... -jiri > > This can easily be extended into a simple object system where the first > bit is a select or an attribute or even a literal and the other things > are indeed method calls. > > Regards, > Martin > _______________________________________________ > Serdev mailing list > [email protected] > http://lists.iptel.org/mailman/listinfo/serdev > _______________________________________________ Serdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/serdev
