On Feb 22, 2006, at 6:33 PM, Bartek Kania wrote:
> I would suggest that a generic API be created for modules to read
> configuration data so the module itself doesn't need to care what
> backend is used to store it.
In a way this is already the case today. Each module calls the core's
config file parser to obtain it's settings. All it has to know is the
keywords under which the data is stored in the config file.
As far as the code is concerned, the changes I suggested will only
replace Digium's built-in INI parser with an open source plist parser
available through the CF/CF-Lite framework.
> Also modules should in the long run be modified not to store
> configuration information internally unless absolutely necessary. It
> should always read the value from the backend when it is needed so
> that a reload shouldn't have to be done for every little change.
> The backend itself will then most likely have to implement some form
> of cache so it doesn't re-read config files or queries databases on
> every request for information from a module.
CF/CF-Lite will give you that. It does cache the settings read from
the property lists and follow on calls to functions accessing key/
value pairs will be on the data in the cache instead of parsing the
property list file(s) all over again unless a synchronise function is
called which as the name suggests synchronises cache and property
list file(s).
> For config files a reload might be the way to tell the config-backend
> to re-read the files and update it's cache. For databases (LDAP, etc)
> a time-to-live could be specified. This would then allow a much
> greater flexibility when designing clusters and such.
One of the interesting things of the CF/CF-Lite property list
architecture is that it works on multiple layers, so called domains.
One of those domains is the network domain which means that several
hosts share a property list. When settings are obtained with a
network domain key (kCFPreferencesAnyHost) the shared property list
will be targeted, which is located in /Network/Library/Preferences,
whilst the local domain has an identically named property list at /
Library/Preferences and the user domain has an identically named
property list at ~/Library/Preferences which is interesting for GUI
apps - less interesting for servers. If no domain is specified, the
parser will first look up the user domain, then the local domain and
then the network domain. This is already used for clustering although
it requires shared filesystems between the cluster nodes. Another
technology which Apple uses for clustering is Bonjour/Zeroconf (mDNS
service discovery, which doesn't require shared files). We have made
an Asterisk plug-in for Bonjour/Zeroconf support and Brian West told
me he will make heavy use of Bonjour for cluster communications in
FreeSwitch.
> The dialplan should be totally remade.
I agree with that.
However, this is something that requires a lot more work than what I
am suggesting. At the same time, there is no harm to continue using
the existing dialplan language but store it in the property list
format, then change it more fundamentally later on.
I also see no harm in making some incremental improvements in the
short term. One such improvement that I would like to make is the
introduction of defined patterns such as
US-tollfree = 18[00,66,77,88]NXXXXXX
or
US-tollfree = 18[00 | 66 | 77 | 88]NXXXXXX
and then use the thereby defined identifier 'US-tollfree' anywhere
you would want to define the pattern. It is totally ridiculous how we
define what a toll free number looks like over and over and over again.
This is the sort of thing that could be incrementally improved with
modest effort while making a very big usability impact.
> ALL of it, not just the syntax.
I agree with that, too.
Yet, I wasn't really changing the syntax of the actual dialplan
language. All I was doing is trying to work out how the existing
syntax can be preserved while representing it in a property list.
> I have some ideas for it but I need to mentally clean them up, and to
> decide if it isn't just better to throw perl/python/tcl/whatever in
> there instead.
> As I recall anthm made a pluggable pbx patch to allow different
> dialplans, maybe we should look into that first.
That can easily be accommodated with the property list system. All we
need is a key/value pair in the master config file that says which
language the dialplan is in and what module is required to understand
it.
> Now I realize that my comments are a bit more far-reaching than your
> initial proposal, and my thoughts are that we make some of the changes
> you propose first since you are already doing them and then move on to
> greater improvements.
Agreed.
regards
benjk
___________________________________________________________
Win a BlackBerry device from O2 with Yahoo!. Enter now.
http://www.yahoo.co.uk/blackberry
_______________________________________________
Openpbx-dev mailing list
[email protected]
http://lists.openpbx.org/mailman/listinfo/openpbx-dev
