On Mar 6, 2006, at 6:49 AM, Daniel Swarbrick wrote:
> Personally, I don't find plaintext plists any more or less human
> readble/editable than XML.
Some people do, some others don't. Hence the motivation to support
both XML and plaintext.
> I thought the ultimate goal here was to have config files in a
> format that
> could be easily manipulated by a GUI...
There are several objectives.
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.
Another objective is to support both XML and plaintext at the same
time so that people who prefer the one will remain compatible with
those who prefer the other.
A further objective is to have a configuration database that supports
cascading domains for session, user, host and network specific
versions of the data where session settings override user settings,
user settings override host settings and host settings override
network (any host) settings. Whilst the user/session domains are of
less use for a server application, it will be very useful for the CLI
utility once it is separated from the daemon and it makes sense to
use the same configuration library/system/format for CLI and daemon.
Further still, once we are getting into larger deployments it will be
a requirement to have managed parameters, that is to say, in a
nutshell, not everybody can modify every setting.
Yet another objective is to use available parsers and abstraction
layer libraries if possible.
One of the benefits of such a system is that it becomes easier to
write GUI front ends, yes.
> on all platforms.
The framework is cross-platform.
>> However, romanised Japanese is well understood by any Japanese below
>> the age of 90, JP-Nihongo is still significantly more intuitive than
>> jp_JP.
>
> I can't believe I'm reading this. You stand up for the use of proper
> English in computing, then you just totally trash thousands of
> years of
> somebody else's culture.
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.
At the end of the day this is about making a user level file
intuitive enough to make its use discoverable. No Japanese under the
age of 90 will find the romanised "Nihongo" in any way unfamiliar.
By contrast, many Japanese wouldn't know how to pronounce or even
describe the underscore/underbar/underline/lowline character. If they
see "en_US" in a file, most won't even recognise this as the place to
change the language settings. If they see "US-English", they will
recognise the parameter for what it is. Of course, many would
probably guess "JP-Japanese".
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.
I am not even certain that sticking both components into a single
parameter is the right thing to do for a user level file. Perhaps two
parameters, one for the language and one for the country/territory is
a better approach.
> Assume that a
> config file contains non-latin characters to describe a language, and
> that file is passed to another system that only has latin character
> sets
> installed. How human readable/editable is it now? What exactly do
> those
> gibberish characters mean on a system that doesn't have full unicode
> support?
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.
>> 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.
>
> I suggest, in order to satisfy this human readable requirement,
> that an
> ~optional~ description is used, in which you can have unicode
> characters.
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.
Thus, you could always stick several representations of the same
setting into a plist. Of course if we do that, we will have the issue
of which alternative takes preference over the other if they don't
agree.
It's probably a better approach to maintain separate files for
separate layers. This way, the plist search order will determine the
order of preference.
> For internal system use, ease of coding, and non-requirement
> of linking against unicode string handling libraries, use ISO codes to
> designate the language.
On the system level, yes, but the adhoc example I presented was meant
to be user level.
regards
benjk
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail
http://uk.messenger.yahoo.com
_______________________________________________
Openpbx-dev mailing list
[email protected]
http://lists.openpbx.org/mailman/listinfo/openpbx-dev
