[asterisk-dev] Asterisk Realtime Updates - LDAP - Enable Option
mjordan at digium.com
Sun Jan 20 19:34:15 CST 2013
On 01/17/2013 03:41 PM, Andrew Latham wrote:
> I did some work to chase down some issues with the documented realtime
> LDAP. I have some patches and a mess of work to commit for
> https://issues.asterisk.org/jira/browse/ASTERISK-20886 which will
> solve the primary issues.
Cool! It's always good to improve support and fix bugs in modules that
provide interoperability. Please make sure the patch goes up for review
on Review Board - there are some changes in that patch that should be
vetted by the development community, as it certainly extends beyond the
scope of a janitor project.
> I am also working on the overall Doxygen
> comments via https://issues.asterisk.org/jira/browse/ASTERISK-20259
> which is a lot of research work.
Yup - improving doxygen comments is a lot of work, which is appreciated.
> I also made an effort to start
> standardizing how modules are loaded (
> https://wiki.asterisk.org/wiki/display/AST/Modules ) which has met
> with little support.
So, I couldn't find much discussion about module loading standardization
other than a brief mention about it during the discussion regarding
configuration file names .
While trying to come up with a unified standard for all modules sounds
like a great idea, I have a feeling that such an effort is bound to fall
prey to reality. As a first step, rather than trying to create a set of
policies from scratch, you should first audit the existing modules in
Asterisk and determine the following:
* What services do they provide?
* What dependencies do the services have? How are they loaded/unloaded?
How are errors handled what said services are registered, and how do
modules handle those errors?
* How do modules handle third party dependencies?
* How can configuration be provided?
* How do reloads affect the services/configuration?
A wiki page answering those questions would be useful, even if a policy
is never crafted.
> I would like to add an "enable = yes/no" to all the realtime driver
> configuration files. res_config_ldap and others try to connect to a
> database/directory server on a default install. I would love to hear
> your thoughts on this.
I'm not sure I understand what you're proposing. Why is an enable option
needed in realtime driver config files, when the presence of a
configuration option in extconfig implicitly enables the usage of that
driver? What is a default install? How can Asterisk know what services
it is connecting to on any random system?
> I would also like some assistance in
> understanding why there are so many configuration parsing routines.
If you haven't already, read the Configuration Framework walkthrough on
the wiki . It explains much of the motivation behind its creation.
Note that it does not replace the key/value pair mechanism afforded by
the ast_config_* APIs, but rather provides a way of tying that
information in a type safe manner to in memory objects. This gives you
an implicit thread safe way of accessing those objects, lifetime
assurance, reload thread safety, as well as consistency in parsing and
application of common business logic.
The next step, afforded by the new "sorcery" API, is to provide a data
access layer abstraction on top of this framework. This lets consumers
of in memory objects to obtain their objects from - theoretically - any
data source using the same operations (e.g., a cache, AstDB, static conf
files (behind the Configuration Framework), ARA backends, and - if
you're really crazy - AMI?). This will be of particular use for
chan_gulp, which will (hopefully) support a new config file schema in
addition to the existing sip.conf schema. That support becomes
transparent to chan_gulp, since all it cares about is getting a
'sip_endpoint' object from the sorcery API - the API itself handles
getting it from sip.conf, gulp.conf, an ARA backend, from an in memory
tl;dr: They have different purposes.
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
More information about the asterisk-dev