Brett Nemeroff wrote: > The original intent was to be a fast, scalable SIP router. Having > runtime queries against your database didn't fit into that model. Not > only that there were no variables. So there was no way to manipulate or > otherwise really use the resultant data.
Sure. But there is a limit to what can be done to meet application-specific needs within the box of the existing modules provided. Along with the UAS features that co-evolved onto the proxy layer, the increasing generalisation of the pseudoprogrammatic route script environment is a logical direction. > I agree that this stuffed into the AVP module seems odd, but given the > AVP module gives the scripting language it's variable capabilities, it > makes sense. I wouldn't dispute that; on the one hand, it is an odd place to put the database interaction functionality, but on the other hand, it is probably the most conceptually self-evident place of the existing module library. I think the ideal answer is C, though - none of the above, make a special module for it. > Before AVPs, you did routing based on module logic and there wasn't > anyway to customize it without writing your own modules by hand. As much > odd as the avpops module integrates arbitrary database interactions, I'm > not sure how I'd change it rather than a typical kind of prepare / > execute/ fetch kind of loop. But that isn't an efficient design for a > real-time switch. I rather like how it is today. It does pose a formidable design challenge; there's not a lot of usefulness in "asynchronous" database calls because it's no good - the response from the database is still needed to carry on processing a request, and that can only happen if the process blocks on database response. What I think is in dire need of more asynchronous-minded renovation is the fact that database calls can block an entire worker process. Since there are no threads used (that is to say, POSIX threads), a spuriously latent database operation will block a whole child process. Child processes handle many requests concurrently in a high-volume scenario. So, that needs to change. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775 _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
