-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. 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. 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. Doesn't realtime do some of this already btw? This is lots of work and I think it's worth to do it, but after a 1.0 release. > * Outlook on how to deal with the dialplan ... > I have not yet put much thought into how to deal with the dialplan at > this stage. My intention is to leave it mostly the way it is now for > the time being. However, I have done some experimentation with how > the existing dialplan syntax could be represented using plaintext > plists. I have also experimented with some ideas how to define > patterns for matching numbers/extentions. > some of this can be seen in a work in progress snippet of imaginary > dialplan ... > http://www.sunrise-tel.com/misc/dialplan.txt > I am not exactly happy with the way line numbers are represented in > there, however, I like the idea to keep an overall framework of > dialplan while at the same time allowing the actual script components > to be configurable and thereby in different languages. The dialplan should be totally remade. ALL of it, not just the syntax. 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. 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. However, I believe we should wait to after 1.0 so we can get 1.0 out as soon as possible and so that people that know * recognize themselves in 1.0. You could still implement it in MacOS X openpbx and then we merge it into trunk after 1.0 Just My 0.02SEK /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/DALckvkFeO3ANARAhhhAKCpcZWNOkQza0e2NHvds+QypjZulQCdFa3n IKzZQnhLA4i5jEJRzwbABdQ= =qklA -----END PGP SIGNATURE----- _______________________________________________ Openpbx-dev mailing list [email protected] http://lists.openpbx.org/mailman/listinfo/openpbx-dev
