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. > 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. > 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. > 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? 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. 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. Overall, I'm right behind benjk's ideas (my preference being the XML config files, although .plist looks manageable too), and look forward to working on them. At the same time, I agree with Bartek that we need to draw a line in the sand and push a stable version out the door, to attract some more Asterisk users over here. _______________________________________________ Openpbx-dev mailing list [email protected] http://lists.openpbx.org/mailman/listinfo/openpbx-dev
