Re: [SR-Users] RFC: rating - ranking system for community

Hi, A few off-the-cuff thoughts, in no particular order: 1. Kamailio does have hundreds of modules of all kinds, and some sort of guide for which ones to use when, or some other schema which would serve to provide some conceptual organisation for the modules, is probably a desirable documentation objective. 2. I am nevertheless wary of any system which purports to "rank" or "rate" components. One obvious reason is that popularity isn't a very good metric for whether something is appropriate for or applicable to a particular purpose. There is a reason the expression "degenerated into a popularity contest" exists in our industry. This is all the more true given (arguably) Kamailio's somewhat unique status as a "toolkit" or a "framework" for building certain kinds of systems and services; it means some of the most useful components in many scenarios might be either obscure, or so broadly general that a highly fact-dependent / situation-specific logic of its relationship to a given scenario is hard to tease out. Would you "recommend" the TM module? Is it widely used? :-) This goes to another, more general problem with ranking components, and that is that the module ecosystem is a wildly eclectic bag of things of very different scope. Without a more rigid preconceived taxonomy to create the right mental categories, meaningful comparisons between modules are difficult to draw, as would be theoretically required for some kind of ranking or any system which purports to raise the profile of some components over others. Kamailio modules fall into at least a few identifiable categories--this is just a half-hearted improvisational stab at it, and probably not very nuanced: a. "Essential" / "core" - while these are technically modules, their feature set is so universal and critical to most non-trivial Kamailio implementations that they are substantially equivalent to "core" functionality. Modules like 'rr', 'tm' and 'pv' clearly fall into this category. One cannot really do anything worthy of remark with Kamailio without them, excluding some exotic cases. b. Broad and holistic systems - complete categories of broad SIP server functionality implemented in more or less one module (usrloc + registrar, presence/pua, auth*, dispatcher, etc.); c. Dependencies of other higher-level modules - the relationship of 'usrloc' to 'registrar' is suitably described by this; if you're using 'usrloc', you're almost certainly using 'registrar', and there are really no meaningful standalone uses of 'usrloc', nor does it expose any route script functions. At the same time, the list of things one may wish to interrogate via RPC/management interfaces are split between 'usrloc' and 'registrar' in ways that make sense to a programmer but which users might find arbitrary. In any case, do you give 'usrloc' a "thumbs up"? What does that even mean? :-) Some modules are hybrids; they have some standalone functionality but are most commonly inputs into a higher-level usage, such as 'xhttp' and its relationship to 'jsonrpcs', or the various presence_* or pua_* subcomponents, some of the auth_* components, ims_*, etc. d. Pure API dependencies of other modules - these expose internal APIs used by other modules and provide no standalone functionality others. One can debate whether 'usrloc' falls into this category, but certainly, 'dmq' is a good example of this, as are the various 'db_*' connectors, and maybe 'keepalive'. e. Niche programmatic functionality - 'htable', 'cfgutils', 'jansson', 'async', etc. This category entails additional programmatic constructs relevant to the "software engineering" aspect of writing config/route script or how processing is done, but do not provide any external services or interfaces as such. f. Broadly environmental - subtly alter the overall way that SIP messages are processed, or add support for new kinds of transports, etc. This would include 'tls', 'ws', 'outbound', and the 'topo{h,s}' modules. g. Language / API / interpreter connectors - 'app_*' modules. h. Highly specific functionality - most other modules fall into this. But some of the functionality is fairly high-level, e.g. 'rtpengine', while others are more low-level and closer to category E, such as 'mqueue'. Anyway, the point here is that I don't think a vehicle to provide community guidance about which components to use, or which would purport to rank them somehow, can be meaningfully separated from the equally vital need to create some kind of taxonomy of modules or, more generally, adequate categories of thought within which such conversations should take place. Kamailio documentation lacks a clear and distinct "metaphysics" in this sense. -- Alex On Thu, Mar 14, 2019 at 09:55:41AM +0100, Daniel-Constantin Mierla wrote: -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/