-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 22 Feb 2006, Daniel Swarbrick wrote:
> Bartek Kania wrote:
>> On Wed, 22 Feb 2006, bkml wrote:
>>> c) configuration data of plug-in modules will be stored separately
>>> from configuration data of the core and by default each module will
>>> have its own configuration file. Optionally, modules may store their
>>> configuration data in a database shared amongst multiple modules. The
>>> location of a modules configuration data and format will be
>>> configurable and stored as part of the core's static configuration.
>> 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.
> That sounds like Asterisk RealTime. Let's design it right this time.
> Lets not store complete flat files in a single database field. That
> doesn't really solve any problems.
It does that?
That's evil!
An directory-like approach(ldap, etc) where each "context" (the [crap]
in .ini-style) is it's own object and they are hierarchically
organized should give us lots of flexibility.
A PRI config could be something like:
PRI - General
|- span1
|- span2
...
etc. And if we need to define complex stuff like a PRI span that is
made up of many E1/T1-lines connected to different cards with
different drivers (now wouldn't that be cool? =)) it could be
something like:
...
|- span3
|- chan1-32: "The sangoma card in slot 2"
|- chan33-lots: "The 4port zap-card in slot 3"
...
Now that would need a chan_pri, but it's a good example of the
flexibility we could have.
>> Also modules should in the long run be modified not to store
>> configuration information internally unless absolutely necessary. It
> AFAIK, config reads are farmed out to an API anyway. That's how RealTime
> was able to be slotted in without modification to existing modules.
Yeah, but the modules load it from that API when doing a reload from
what I can see. That's why iax/sip/etc has lots of peer lists and
such. Now some of these would be hard to completely remove, unless we
can design an API that can tell a module about a change in the config
when adding a new peer etc. How that would be done I don't know,
unless LDAP and others have hooks that are called when the db is
changed. Rescanning the entire DB and seeing what changed isn't that
good.
>> 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.
> Maybe a stat() of the file, and if the file has been updated since the
> last reload, then parse the config file again.
That could be a problem if the file is picked up too fast, a script
writing it might not have finished. But it could be an option if the
user wants it.
> I use RealTime in OpenPBX using the res_config_pgsql driver I wrote. At
> the time I wrote it, it seemed like a great idea, since it meant that a
> lot of the PBX config could be managed by external config front-ends,
> and it reduced the number of times I had to risk doing a 'reload' of the
> PBX (we all know how Asterisk used to crash a lot when doing this).
> However, I've since learned that a lot of stuff only half-works with RT.
> You can't even do a 'show sip peers' with RT, or use MWI, unless you
> turn on 'rtcachefriends' in sip.conf. Once you do that however, you have
> to do a 'sip reload' whenever you delete a SIP entry from your database,
> to update the cache. Basically you are back to square one.
Yeah, that's something I would like to get rid of.
Most of it can be done on a "get config as required" basis. If a new
peer contacts the pbx it can look for it in the config and see if it
is there. But for peers that we keep track of (qualify=) or peers that
we initiate contact with it's a bit harder.
> I would like to move more towards using LDAP for storing
> SIP/IAX/voicemail accounts anyway, and think a user-adjustable TTL is a
> great idea. I'd also like to see RealTime ripped out (but not just yet,
> not until it's been replaced by something, since I currently use it!).
> RealTime was a great big kludge, very poorly designed. The only reason I
> work with it is that it's marginally better than manipulating ini-style
> files.
Which reminds me, we should have a generic user model in opbx. So
agents, vm's, app_authenticate can share pin-codes and such. It's
annoying having to put the same data into three files.
/B
- --
* GPG-Key: http://evil.gnarf.org/mrbk.pgp
A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?
- -- http://www.i-hate-computers.demon.co.uk/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFD/GW/ckvkFeO3ANARAj2tAJ0eq4NGU3DnTS5cMUIc1BACgTS0YwCdE80f
OGoe7jpmjQnIKuXa/a8b5u0=
=zdC4
-----END PGP SIGNATURE-----
_______________________________________________
Openpbx-dev mailing list
[email protected]
http://lists.openpbx.org/mailman/listinfo/openpbx-dev
