Bogdan, Bogdan-Andrei Iancu wrote:
> When comes to none-SIP related stuff, there is a logical limit of what > should be in or not - after all we do a SIP server and not a DB wrapper, > neither a XMLRPC server, not an advanced language interpreter (and so one). I can certainly appreciate that. In principle, I agree that at the end of the day, underneath it all, OpenSIPS is a SIP proxy, along with some lightweight UAS features (registrar, presence user agent, etc.). It's still much more a piece of service delivery *infrastructure* - it is low-level relative to some other network elements that frequently make their appearance in the open-source VoIP ecosystem. No argument there. But I think this does have to be balanced with the reality that a great deal of the OpenSER technology stack's usefulness does come from the fact that it can be deployed in application-aware configurations, the extensibility of the route script, and so on. This ability to add intelligence and integration paths is precisely where it has an edge over the expensive commercial proxies and, in certain situations, SBCs. > To give you an example of how I see this delimitation of what should be > in OpenSIPS and what not. Let's take the DB case (anyhow the discussion > started from there): the current DB support in script is a very decent > one (via the avpsops functions) - you can do mostly all types of queries > and DB interaction. If you need something more complex (from DB), I > think you must work on the DB side and do the enhancements there. Make > no sense to invest effort in doing super DB stuff in a SIP server, when > the DB engine itself may already offer this support. Sure, but taking advantage of some of the more sophisticated DB capabilities on the back side also requires adequate interfaces on the front side. For example, how does one deal efficiently and easily with multiple rows returned by a DB query? At present the only way is to iterate through AVP arrays in a rather obfuscated manner that is hard to understand and not particularly terse. All this benefits from improvements to language syntax and semantics as well as the DB layer. > Again, an example - couple of weeks ago I had to interface OpenSIPS with > some really complex data structures in a postgres DB - the solution was > simple - some postgres procedures were created to hide the DB complexity > and also to incorporate some logic. Form OpenSIPS point of view, the > problem was reduced to running a select over the procedures. I completely agree. In fact, this is exactly how I have been doing my work (I almost exclusively use Postgres) for years precisely because of the fact that the route script does not have the capabilities of a general-purpose programming languages, including native support for nontrivial primitives and other semantics that are needed to do that kind of logic programmatically. I rely very heavily on stored procedures and triggers. Nevertheless, the interface could use some enhancements to make this coupling easier. It's just little things. Like, for example, right now, if you issue a DB query that returns no rows, you need to use is_avp_set() to check whether the corresponding AVP(s) are set. > So, the effort is better focused on SIP part rather is peripheral > interaction, where we can use the already existing and specific tools > and mechanism. Nevertheless, a lot of the peripheral tools hold the key to a great deal of the value. I invite you to remember why OpenSER grew to such popularity after the fork with SER in 2005: it is the mass of community-contributed modules and novel functionality. SER may have focused on a good core, but OpenSER could be said to have won precisely because of the additional baked-in capabilities. Whatever your opinion of bells & whistles modules, I think it is very important to preserve the inherent benefit offered by most open-source software compared to proprietary alternatives: the integration paths. Asterisk for example has AGI and the Manager interface, which both allow outside processes and outboard logic controllers to touch and manipulate the engine. MI[_DATAGRAM], XML-RPC, and a relatively flexible route script are all very important for that reason. The capability to integrate is paramount above all else, and is a governing factor in the technology choice. > About the place of the DB related stuff - well, originally they were > operating only with AVP and this is why they were put in the avpops. > Now, indeed, there is no dependency for this, but the questions is what > will be the advantage for a users of moving some functionality in a > separate module ? I fail to see any... Expanded database-centric functionality, especially free from the constraints of unrelated AVP constructs, such as the need to define an avp_table as a modparam even if one is not going to use it. -- Alex -- 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 Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users