3 Mar
2016
3 Mar
'16
7:30 a.m.
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
3 Mar
3 Mar
10:50 a.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, March 7-9, 2016 - http://www.asipto.com
10:54 a.m.
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
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
7 Mar
7 Mar
6:57 a.m.
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
3229
days inactive
3233
days old
3 comments
3 participants
participants (3)
-
Alex Balashov -
Daniel-Constantin Mierla -
Sven Neuhaus