On Mar 5, 2006, at 10:14 PM, Daniel Swarbrick wrote:
> bkml wrote:
>> We have specifically settled on plaintext format (and not XML or
>> binary) because we wanted the property lists to be human readable and
>> editable. Using human readable keywords is an important part of that.
>
> When did we settle on that? The last I heard, both plist and XML would
> be supported transparently by the same library. While plist might be
> dominant on your development platform (MacOS), XML is a cross-platform
> standard. I reckon XML editors are far more common than plist editors,
> not to mention the fact that lots of script languages have good
> support
> for manipulating XML via DOM methods.
The default on OSX is XML plists, not plaintext, because OSX users
are far less likely to edit files by hand than users on most other
platforms. On Linux and BSD users are more likely to want to edit
files manually and there is a lot of sentiment against using XML for
this reason.
However, the framework handles different formats transparently, so
yes, XML is supported as well, but the consensus was that the
*default* should be human readable/editable as well as the point that
there should be a human readable/editable option in addition to XML
in the first place.
>> Multiple languages can also be supported this way. OSX/Darwin does
>> this sort of thing all the time via separate sets of plists, one for
>> each supported language/locale.
>
> Gee, that sounds efficient. Easy to maintain too! :P
It is a lot easier to develop for and maintain than any other system
out there, yes. And it's certainly more efficient than Asterisk's INI
parser.
>> Also, a common user friendly approach for language selection is to
>> present each language in its own language, ie. Finish could be "FI-
>> Suomi", that's an approach worth considering for a resource intended
>> to be human readable/editable.
>
> Ok, we'd better make the config files written in UTF-8 then, since
> there
> are many languages that will need to be written using non-Latin
> characters. Have you thought about how you're going to write
> "JP-Nihongo" in native Kanji? Even if you do manage to write
> Nihongo in
> Kanji, what does JP mean to a Japanese person? They don't call their
> country Japan, they call it Nihon or Nippon! Even UTF-8 doesn't cover
> all the possible characters from every single language in the world.
The framework supports Unicode, so if we wanted to make use of it,
yes, we have that option.
However, romanised Japanese is well understood by any Japanese below
the age of 90, JP-Nihongo is still significantly more intuitive than
jp_JP.
> Mmmm, what's that I smell? Is it a can of worms being opened?
> C'mon, do
> you think the average *nix shell is gonna have support for all those
> fancy character sets, and properly display language names written in
> their native script? No!
the average shell / terminal on my system certainly does ;)
> Leave that for the end user GUI to display,
> which most likely will have those character sets installed.
First, the end user GUI reads the unicode strings from the
appropriate property list. This is however besides the point because
we are talking about a file that is *intended* to be human readable/
editable.
> ISO standards exist for a reason.
I am not saying the system shouldn't use them for internal
representation, just not in a file that is intended to be human
readable/editable.
BTW, the example I posted was just an adhoc. It may turn out
differently, yet, whatever form it will take, the requirement for it
to be human readable/editable should be satisfied.
regards
benjk
___________________________________________________________
NEW Yahoo! Cars - sell your car and browse thousands of new and used cars
online! http://uk.cars.yahoo.com/
_______________________________________________
Openpbx-dev mailing list
[email protected]
http://lists.openpbx.org/mailman/listinfo/openpbx-dev
