Tilghman Lesher wrote: > On Saturday 08 December 2007 00:51:44 Philip Prindeville wrote: > >> Tilghman Lesher wrote: >> >>> On Friday 07 December 2007 20:12:12 Philip Prindeville wrote: >>> >>>> Darryl Dunkin wrote: >>>> >>>>> You can store most of the configurations in a database which may be >>>>> more accessable to you. >>>>> >>>>> Perl can also parse these configurations quickly enough if you know how >>>>> to use the input record seperator ($/) properly. >>>>> >>>>> The only thing Asterisk will not store which you would probably need is >>>>> the actual MAC address of the phones themselves. This may be done >>>>> easily enough as comments in the users sip.conf section. >>>>> >>>> That's sort of my point: that you have to reinvent it, and it's easy to >>>> get wrong. >>>> >>> XML wouldn't make it any less wrong. There's a difference between >>> parsing it syntactically (which XML fixes) and parsing it semantically >>> (which XML does not). >>> >>> In fact, I find the configuration files, as they are now are much EASIER >>> to parse than XML. With XML, you need to load up a whole state engine to >>> ensure the config is properly formatted. At the simplest level, the >>> config file as-is is simply a set of key/value pairs, which syntactically >>> is very easy to parse. >>> >>> Part of the allure of the current format is also that it is human >>> readable, which assists in manual editing. I'm not sure what part of the >>> universe you have be from to make XML human readable (or more >>> importantly, human-editable), but I am quite sure it is not from this >>> planet. >>> >> Well, after hand-coding HTML and SGML for 15+ years, XML isn't all that >> much of a stretch. >> > > And so can I, but to most people, XML looks like gobbleygook. BTW, 15+ years > for a markup language (HTML) that has only been around for 14 years? >
See my postings on www-html and www-talk while it was in draft stage. >> More to the point though, there are some excellent schema-driven >> configuration managers for XML, so you wouldn't have to edit the files >> by hand. >> > > And that puts an additional requirement on developers, that each know how > to manually (and correctly) edit the schema file to ensure that new options > added are correctly specified. You haven't eliminated complexity at all, > you've just shifted it to someone else. > By that logic, we'd have no new operating systems, no new programming languages... Yeah, all progress entails a learning curve. > Also, you're adding another tool in the chain that people must learn in order > to administer an Asterisk setup. Right now, people can use whatever editor > they like, whether that's vim, emacs, nano, joe, or some other editor. They > learn one editor tool and can use it generically for all purposes. By adding > another requirement, you're increasing the barrier to entry, which is the > opposite direction that we want to go. > > And finally, another person has already made the point that most XML editors > are graphical in nature. A great many Asterisk installations are installed in > locations where a graphical front end is not practical. Not only does that > mean that your options for text editors are limited, but they are unlikely to > be easy to use (or learn how to use), compared to full screen text editors, > which have been around for over 20 years and are fully mature software. > > Going back to my original posting, I was also suggesting that the parse tree from Asterisk could be read in and then dumped out as XML, so that other software could then ingest it... using it as a common format for passing configuration from one package to another. -Philip _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
