It would be better to have different operators for strings and for
integers. Right now we have '+', '==' and '!=' that can be used both for
strings and integers. The problem with this approach is that it makes
some optimizations impossible, especially when combined with dynamic
typed variables (avps or pvars). '+' is especially bad because one
can tell what type ($v + x) has only at runtime.
I think having perl like operators would help a lot:
- '.' for string concatenation (instead of reusing '+'), e.g.:
$v= "foo" . "bar"
- 'eq' instead of == for strings, e.g.: $v eq "bar"
- 'ne' instead of != for strings, e.g.: $v ne "bar"
We could support them right now in parallel with the old ones and
obsolete +, == and != for strings in the future (but that means we
still cannot optimize '+' in all the cases) or switch right now
(maybe with some old compat switch which will support old scripts
style).
The question is how much are they used right now. While I think '==' and
'!=' are used quite often, I'm not sure about '+' for strings (and '+'
is the most important anyway).
Note: we can still support '==' and '!=' for condition tests not
involving variables (e.g. method=="INVITE", uri=="sip:foo" a.s.o.).
Another advantage that this change would bring is better type checking
at startup (more errors flagged without having to run the script) and
possible implicit conversions (e.g. int to string or string to int) if
we decide to support them.
Any comments?
In the future it would also be much better to have typed script vars
(e.g. int $var1). This would help a lot in checking the script for
correctness. With the dynamic typed vars, one has to run the script to
find errors. It would also help in optimizing, but not so much if we
separate the operators, like above.
Andrei
As you probably have noticed the git repository for sip-router is now
online.
It was started from ser core and tm.
git urls:
git://git.sip-router.org/sip-router
(read only)
http://git.sip-router.org/sip-router
(read only, slower, git://... recomended)
ssh://git.sip-router.org/sip-router
(read write but account on git.sip-router.org needed)
Web interface: http://git.sip-router.org/cgi-bin/gitweb.cgi
Branches acl: the repository is setup so that you can write/commit
only to the following branches:
<your_username>/.*
tmp/.*
master
We'll add access to more branches as needed (I've added this rules to
avoid creating lots of "root" branches by mistake, e.g. git pull
from a local branch without a refspec).
Please create the commit messages following the git convention
(start with one short line, preferably less then 50 chars summarizing
the changes, then one empty line and then a more detailed description).
See:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#creating-g…http://www.tpope.net/node/106
Quick git introduction:
# clone the repo into the sip-router directory
git clone git://git.sip-router.org/sip-router
cd sip-router
git branch -a # show all branches
# create a local branch based on origin/andrei/mod_f_params
git checkout --track -b my_branch origin/andrei/mod_f_params
git log # see commit log
git log --pretty=oneline # only the first line from each commit
vim Makefile.defs
git add Makefile.defs
git commit # or git commmit -a to skip the add step and commit all
# changed files
# push changes back (note you need ssh access for this)
# note: the next command will fail, unless your username is andrei :-)
# publish changes on the local "my_branc" to the remote
# andrei/mod_f_params
git push origin my_branch:andrei/mod_f_params
# or push them into the master branch if you are sure about them
git push origin my_branch:master
For more info about git try:
http://git.or.cz/gitwiki/GitDocumentation
and if you want to know how it works:
http://eagain.net/articles/git-for-computer-scientists/
(highly recommended)
CVS access:
CVS_SERVER="git cvsserver" cvs \
-d :ext:andrei@git.sip-router.org/sip-router co master
(instead of master you can use any other branch name that doesn't
include a '/')
The initial checkout takes a while, but after that cvs update seems fast
enough.
SVN access: unfortunately we do not have it. It looks like the
git svnserver is in the project stage (there is some python code but not
runnable yet). There is a way around it, but it would be quite complex
to setup: a git to svn gateway and then svn to git imports.
Other repositories on git.sip-router.org:
ser - entire ser updated from cvs
ser_core - only ser_core, automatically updated from cvs, read-only
test - test repository, contains an early sip-router version, it has the
same access rules as sip-router (if you have something you want
to test, please use it rather then trying directly on
sip-router).
Special thanks go to Jan, who not only did setup git.sip-router.org
(including automatic cvs sync for some of the repos), but he's also
hosting it on one of his private machines.
Andrei
Heisann,
I know everyone is busy getting this project off the ground, but I
think it might be worthwhile discussing the future on the side and
anyway, this regards the database API which sort of is currently being
nailed down.
Since we were talking about it internally, I was thinking a bit about
the future of usrloc. It has this thing where it caches entries in
memory. Now, technically usrloc is just a database (or maybe a database
on top of a database). Wouldn't it make sense to get rid of it and
instead implement a database module that caches and then simplify the
registrar module to use database queries directly?
This has the benefit that other modules can suddenly use caching, too,
if they want. In SER, the domain module for instance already does some
caching, so there is some code replication.
I believe the database API to be simple enough to provide caching
especially since the new model with pre-registered queries allows the
cache to be set up with those queries in mind.
Regards,
Martin
[crossposting since this is of general interest]
On Nov 12, 2008 at 00:30, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
> Hi Miklos!
>
> This sounds great. Can you make a sample function which uses the new
> feature?
We are thinking of doing a dns_prefetch module using this.
The sip-router.cfg will look like:
route{
...
dns_prefetch("uri", ROUTE_DNS_OK);
# end of script
}
route[ROUTE_DNS_OK]{
if (dns_error){
...
}
# continue normal processing
# the uri was resolved and is in the dns cache
...
t_relay()
...
}
However don't expect something quickly as everybody is quite busy and we
would still need to write a dns resolver process pool (time consuming).
Note that this is not the "final" async. solution since it's not
transparent for the script writer (scripts would have to be written in a
special way), works only with tm and it's also a little inefficient for
dns usage.
In the long term we will have completely transparent async. support for dns
and maybe db lookups (though it's controversial if we really need it for
normal db lookups). This will take much longer and will require among
other things reviewing all the global variable use (most of the global
variables will either need to be registered or allocated in some known
special place).
If Miklos doesn't beat me to it, I'll probably start working on it only
after the core merging is complete.
>
> Can this also be used for DNS lookups and TCP/TLS connection setup?
Yes for DNS (see above) and in general for any route-level async processing
involving tm (e.g. lookup some part of the message in a slow DB and
execute automatically another route when the DB responds).
It cannot be used for TCP/TLS, but it's not needed anyway. In ser TCP
connection setup and TCP send is already asynchronous, at least if
you have tcp_buf_write=yes in ser.cfg (I agree it's not a very well
chosen name :-)). TLS does not support it yet, so if you use TLS
you should not set this option (that's why it's not yet the default).
TLS support for it requires non-trivial changes in the tcp core and it
will probably come after the merge (it's started already but far from
finished).
(BTW: most of the core new options documentation in ser can be found
in NEWS)
Andrei
>
> Further, also for Kamailio cooperation better documentation would be
> needed. Thus, instead of writing long CVS commit messages I think it
> would be better to write the text into the module documentation, and
> then copy/paste it into the CVS commit.
>
> regards
> Klaus
>
> Miklos Tirpak wrote:
> > tirpi 2008/11/10 13:47:03 CET
> >
> > SER CVS Repository
> >
> > Modified files:
> > modules/tm t_cancel.c t_fwd.c t_reply.c t_reply.h
> > tm.c tm_load.c tm_load.h
> > Added files:
> > modules/tm t_suspend.c t_suspend.h
> > Log:
> > t_suspend() and t_continue() functions are introduced.
> >
> > These fuctions can be used by other modules to implement
> > asynchronous actions: t_suspend() saves the transaction, returns its
> > identifiers, and t_continue() continues the SIP request processing.
> > (The transaction processing does not continue from the same point
> > in the script, a separate route block defined by the parameter of
> > t_continue() is executed instead. The reply lock is held during the
> > route block execution.) FR timer is ticking while the
> > transaction is suspended, and the transaction's failure route is
> > executed if t_continue() is not called in time.
> >
> > Missing: msg lumps are saved by t_suspend() and are not updated by
> > the subsequent t_relay(). This means that the modifications made
> > between them are lost.
> >
> > Revision Changes Path
> > 1.32 +7 -2 sip_router/modules/tm/t_cancel.c
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_cance…
> > 1.107 +8 -2 sip_router/modules/tm/t_fwd.c
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_fwd.c…
> > 1.162 +4 -4 sip_router/modules/tm/t_reply.c
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_reply…
> > 1.31 +7 -1 sip_router/modules/tm/t_reply.h
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_reply…
> > 1.1 +154 -0 sip_router/modules/tm/t_suspend.c (new)
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_suspe…
> > 1.1 +42 -0 sip_router/modules/tm/t_suspend.h (new)
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_suspe…
> > 1.177 +3 -1 sip_router/modules/tm/tm.c
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/tm.c.di…
> > 1.31 +11 -1 sip_router/modules/tm/tm_load.c
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/tm_load…
> > 1.31 +4 -1 sip_router/modules/tm/tm_load.h
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/tm_load…
> > _______________________________________________
> > Serdev mailing list
> > Serdev(a)lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serdev
>
> _______________________________________________
> Serdev mailing list
> Serdev(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev