Andrei Pelinescu-Onciul wrote: > On Jul 03, 2008 at 11:33, cco <[EMAIL PROTECTED]> wrote: >> On Thu, Jul 03, 2008 at 09:33:04AM +0200, Martin Hoffmann wrote: >> > >> > o Drop the ser.cfg language and use Python as the script language. >> >> cristian: what about this (even more bold): >> >> o Offer the possiblity to choose your favorite scripting language >> for writing ser scripts. (i.e. multiple scripting languages, >> including ser.cfg)
I picked Python because I know it has a really nice foreign language interface. > Yes, I agree with this. (for the record I'm a perl lover and passionate > python hater). No real surprise there ;) > I also believe that neither perl nor this other > scripting language you mentioned are fast and memory friendly enough for > heavy use (think 10000-20000 requests/s). That may be an issue. However, we should keep in mind that with more features added, the SER config language will become slower and more memory hoggy, too. Whether the performance of whatever scripting language is enough depends for a big part on what you are doing. If you stick to simple things, the performance may be enough. If you start doing weired stuff, obviosuly you will be slowed down. On the other hand, you can do all sorts of weired stuff if you want to. That may be worth having to put in another machine. On yet another hand, I am currently toying with the idea of moving the generation of the route set out of SER completely. But that is another thread yet again. >> o Reload/reparse of the script at run time; the next >> message/transaction is processed using the new script. >> >> what do you think? > > I agree. I don't think is critical, but it would sure be nice to have. Good point. Actually forgot that one. > Provided we move the script tree in shared memory, Alternatively, do as Apache does: Kill off all the old processor children and fork new ones with the new config. > If we are at it, we should also pack all the abstract syntax tree that > (in which the script is converted) into a compact binary blob. This > would allow easy serialization (e.g. dump binary config into a db and > load it directly on other machines) and would have much better cache > locality. I smell portability issues. And don't quite see the point. Regards, Martin _______________________________________________ Serdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/serdev
