Hi Emmanuel,
Emmanuel BUU wrote: > Hello, > > First of all, I want to stress that the whole concept of message > scripting is a fabulous asset. It enables us > to adapt to so many situations without recompling C code. I have the > feeling that the whole concept has emerged from a rather practical > and performance oriented approach (which is good). and we do not want to loose that :) > We should maybe look > at what we idealy would like: > > We want to be able to modify the message and see the modification "in > real time". yes, that is one of the major draw backs at the current time. > For some values, > we also want either to undo some changes (mainly the module developpers) > or access the original values > the scripts writers. > > So IMHO there should be some place where the original message stand, > preparsed by the core. The modifications should be applied on a > preparsed copy > and the module developper should be able to access both but modify only > the one that is intented to handle the modification. At the end of the > processing > the modified message should be translated from a parsed form to a text > buffer. > > This process might be slower than the original lump model that is highly > optimized but it may lead to a more sold ground. > See my suggetion here - http://lists.opensips.org/pipermail/users/2010-April/012401.html Maybe I should try to place it on wiki to be easier to read ;) > I agree with the remark about branch isolation. > thanks, Bogdan > Emmauel > > Bogdan-Andrei Iancu a écrit : > >> Hi, >> >> sorry for crossposting, but I thing this topic is interesting both for >> users (as experience) and for developers (as solution). >> >> 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 : >> Advantages: code is there and works; the mechanism is very fast ; >> no need to re-parse the message after the parsing >> Disadvantages : from script or code, you are not able to see the >> previous changes you did on the message, like: >> if you remove a hdr, it will be marked to be removed, >> but you will still see it there after the removed >> if you add a new hdr, you will not be able to see it >> (it will be actually added only when the message will be sent out) >> if you replace the contact hdr (like after >> fix_nated_contact() ) will not see the new contact, but the old one >> trying to apply 2 changes in the same area (like >> changing twice the contact) will result in bogus result. >> >> 2) find a new approach that will allow to push in realtime the >> changes on messages >> Advantages: the change will take affect instantly, so all the >> disadvantages from 1) (as user experience in operating opensips) will >> disappear . >> Disadvantages : the code will probably be slower (the changes >> part), but will speed up other parts of the code (where you need to >> manually identify the prev changes); >> changed parts of the SIP message will require re-parsing >> (so the code will have to check the state of a header (if parsed or not) >> before each usage) >> you will not be able to undo changes on the SIP messages in >> an easy way (for example during the parallel and serial forking on >> per-branch changes) >> >> 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 would like to hear some opinions from both people writing scripts and >> people writing code. >> >> Thanks and regards, >> Bogdan >> >> >> > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- Bogdan-Andrei Iancu www.voice-system.ro _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
