On 28/04/10 11:40, Bogdan-Andrei Iancu wrote: > So, right now the code for 2.0 got to a stage were we need to "apply" > changes on the received messages (like adding VIA headers, changing > headers, etc). And before starting the work on this area, I would like > to get some opinions on the available options: > > 1) keep the current mechanism for changing the SIP messages by using > lumps that are applied only when the message is sent out :
The problem for me was that sometimes you want to change things that are affected by by previous calls you have to do. For example you cannot easily fix the contact and the apply a parameter to the end. You cannot put those 2 changes together, since one comes from the script logic and the other from the internal function. (problem I run into in the nat proxy - after masking I cannot add ;expires=...) > 2) find a new approach that will allow to push in realtime the > changes on messages There's some middle ground here, where you can at least use fast string operations (yay - yet another string type!). I'm not sure if this would play well with custom allocators, but a couple of years ago I was using http://www.and.org/vstr/ - it promises modifications without realloc() calls (does something like lumps internally). Afair it was good quality and not modified for a long time. But you'd still have to find a way of quick reparsing the message... region invalidation, so you don't reparse more than needed? first-known-dirty, first-known-good pointers? Most people don't need reading the changes back really, so if you only marked the range of headers as invalid, it could create a nice lazy-reparsing solution. > So this is the dilemma: if the current mechanism (with applying changes > at the end) such a bad user experience (scripting) in order to try for > 2.0 a different approach ? I like changing changes and I like the speed... hard choice. If partial reparsing is not realistic, maybe you could just approach it from a completely different prespective. Since the new routing is available from a normal programming language anyways, maybe just exporting the interface to lumps is enough? This way you could do the change of a change if you *really* wanted it. Or what the kama/s-r guys are doing - add a function that "flattens" the message and reparses it on request. Stan _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
