Hi,
a suggestion for Kamailio 5.0 is to get rid of the cryptic, case sensitive pseudo-variable names. Instead we replace them with descriptive names like the ones already provided by the TLS module.
The current pseudo variables are a constant nuisance unless you deal with Kamailio every day and know them all by heart. They are an unnecessary barrier for new users learning Kamailio and force you to refer to the documentation more often than necessary.
Ideally there would be a script to replace old variable names in configuration files with the new ones to make the transition less painful.
-Sven
Hello,
Personally, I have to go to the documentation anyhow, especially for functions, where the name is anyhow suggestive, but there are too many to remember by heart and know their parameters.
Also, one of the benefits for short names is a compact string when printing them with xlog() or as part of function parameters.
Anyhow, it is possible to have different names for same variable. For example, even right now:
- $ruri is same as $ru - $ruri.user is same as $rU - $ruri.domain is same as $rd
So if the people wants alternatives, it is easy to add -- just exporting same structure as for an existing PV, but with a different name.
Moreover, I do not think one (or many) would like $xavp(x) to become $extended_attribute_value_pair(x) ... so new names should not make the config look ugly...
Maybe the best way to move forward on this is to build a list of PVs that should get aliased names and decide which should be those. I hope not to start some flame wars, given it won't be any technical, but just taste about names and patterns...
Cheers, Daniel
On 03/03/16 13:30, Sven Neuhaus wrote:
Hi,
a suggestion for Kamailio 5.0 is to get rid of the cryptic, case sensitive pseudo-variable names. Instead we replace them with descriptive names like the ones already provided by the TLS module.
The current pseudo variables are a constant nuisance unless you deal with Kamailio every day and know them all by heart. They are an unnecessary barrier for new users learning Kamailio and force you to refer to the documentation more often than necessary.
Ideally there would be a script to replace old variable names in configuration files with the new ones to make the transition less painful.
-Sven
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
I would agree that, given a sufficiently large number of variables:
- It is inevitable that even long-time Kamailio developers and experienced professionals have to go to the documentation to find what they need. One cannot reasonably expect to have everything memorised without consulting reference material. It's that way with any nontrivial API, library, toolkit or framework.
- All other things being equal, short PV names are much better than long ones.
-- Alex
Am 03.03.2016 um 16:54 schrieb Alex Balashov:
I would agree that, given a sufficiently large number of variables:
- It is inevitable that even long-time Kamailio developers and
experienced professionals have to go to the documentation to find what they need. One cannot reasonably expect to have everything memorised without consulting reference material. It's that way with any nontrivial API, library, toolkit or framework.
- All other things being equal, short PV names are much better than long
ones.
I don't mine terse names. But case sensitive variables are just crossing a line. The only other place I've seen that was in sendmail and that was in the early 90s. And ordinary admins used m4 macros instead of dealing with sendmail.cf directly.
There is a good reason no one else is do case sensitive variable names! Perhaps as a first step we can get rid of all variables that exist with different meanings depending on the case of the variables, and work from there.
Is it really preferable to have $bF instead of, say, $branch.hexflags?
I like the .user and .domain suffix examples Daniel posted. Are these transformations also writeable?
-Sven