On Jul 03, 2008 at 11:33, cco <[EMAIL PROTECTED]> wrote: > On Thu, Jul 03, 2008 at 09:33:04AM +0200, 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. > > > > Before I go into your points, here's what I have: > > > > o Loops. While you can already loop recursively to a points, an > > iterative loop would be nice. > > > > o Includes or some sort of module mechanism. This is currently done > > using M4 or CPP. Maybe we can have a native include mechanism. > > Alternatively, SER can use a pre-processor such as CPP all by > > itself. > > > > o Functions instead of routes. Allow the definition of routes with > > arguments and a return value and drop the distinction between > > functions provided by the core or modules and what you define in > > your script. Together with the include mechanism, this allows the > > creation of libraries. > > > > And, just to be bold: > > > > 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)
Yes, I agree with this. (for the record I'm a perl lover and passionate python hater). 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). As a matter of fact it would be quite easy to implement provided that we move all the config vars. declaration from cfg.lex/cfg.y to C code (so that we would have a way of knowing at runtime all the config vars) and we do the function signature + fixup changes. So the only ugly and very boring part would be cleaning up cfg.lex and cfg.y. > > now, in the era of "dynamic computing" (sorry, I just couldn't help not using > the buzzword) there is another thing we should think of: > > 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. Provided we move the script tree in shared memory, it would even be quite easily doable using Miklos dynamic cfg stuff, that we already have running. There would be a few exceptions, like changing listening addresses and maybe changing db connections. 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. Andrei _______________________________________________ Serdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/serdev
