According to James Sizemore: > > Problem will all XML configs: > 1. They are nearly imposable for a human to read, for any non trivial > config.
It's about like reading HTML source -- it doesn't have prose-like flow, but it can be read and understood without a complex editor. In my experience, the editor's most crucial function isn't convenience, it's enforcing the XML DTD so a syntax mistake doesn't break or confuse your application. > 3. I personal find it easer to parse a human readable config file, then deal > with any XML library that I have ever seen. As do many other asterisk administrators. In my small-scale asterisk system, it's not a problem to deal with asterisk's config format. But when scaling up to a large network, I could see the need to develop tools specifically for asterisk Configuration Management (CM). Currently, any management scripts would need to deal properly with asterisk's unique config format. XML might assuage this possible future headache. Said another way, I didn't know about CM tools when I first learned Cisco's IOS using a couple low-end routers. I didn't really want to deal with the overhead of CM when I managed a network of a dozen or so Cisco routers. However, the CM idea became spiffy when my network grew to about 60 network elements, and absolutely necessary when consulting for a global route-switched network of hundreds of network elements. > 5. So what was the point of XML again? They is none! Tell that to the folks that have used XML to escape the hell that is EDI. XML makes a lot of sense when data needs to be freely exchanged between/ among environments that do not otherwise share a common data schema. So far, nobody has described another environment with which asterisk config data should be shared... so yes, XML seems a buzzword for buzzword's sake at this point. I suggest that since many asterisk configs are read only at startup, the benefit of having XML configs is somewhat limited to configs that respond to the "reload" CLI command. Further, asterisk-familiar programming resources are constrained to a small group of folks, whose time is quite valuable both to their companies and to asterisk users that await "hard" features and bug fixes. XML config support falls WAY down on the priority list from where I'm standing. If XML is important to your needs, why not write a translation script to parse XML and write the asterisk configs? Scripting languages abound and are appropriate to the task. Obviously, the transaltion script could grab your XML and write fresh asterisk configs every time you started asterisk. Just a thought, rm ------------------------------------------------------------------------- Roderick Montgomery [EMAIL PROTECTED] <URL:http://thecomplex.com/> the fool stands only to fall, but the wise trip on grace... [Sarah Masen] ------------------------------------------------------------------------- _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
