bkml wrote: > One is to have formalised syntax and semantics which INI doesn't. > There are as many definitions out there for INI as there are > implementations of it. > > Another objective is to be able to structure the configuration data, > such as nesting sections for example. INI doesn't meet this objective > either.
I'm all for using XML, and understand clearly its advantages over ini-style. I've used XML in development projects for about the last 5 or 6 years. I think it sometimes gets a bad rap by people who don't really understand by what is meant by representing a "complex but arbitrary object". This often leads to to debates about whether we are simply using XML for XML's sake. I do however believe that ini-style is rapidly coming to the end of its useful life for projects such as this. > It may come as a surprise to you, but Roman characters, or Romaji as > they are called over here, are part of Japanese daily life and > culture. They are even part of the Japanese JIS character set. It comes as no surprise to me at all - I studied Japanese language for four years. I speak a moderate amount of Russian, and fairly fluent German. So that's four languages and five alphabets I have experience with. I've worked as an IT manager in Russia - I know all too well the hurdles of managing Unicode/code pages, on a mixture of FreeBSD, Linux and Windows platforms. > In any event, I didn't say that "CC-Language" is the ideal format for > this. All I am saying is that it should be discoverable even for > somebody who is unfamiliar with the ISO codes. Optional text description next to the ISO code, or native language representation via a GUI. > Yet, again, I didn't say we should do this. I said that the framework > supports Unicode and that we have the option to use Unicode if we > wanted to. The framework may support Unicode, but I'm fairly sure OpenPBX as a whole is a long way from being Unicode-safe. > All parameters are optional. That's one of the nice things about the > framework. It won't stop parsing if some parameter isn't there and it > won't stop parsing if a parameter is there that your software doesn't > actually use. One of the nice things about open standards is that everybody can have their own. _______________________________________________ Openpbx-dev mailing list [email protected] http://lists.openpbx.org/mailman/listinfo/openpbx-dev
