Jim,

> >I think this don't fit well.
> >
> >For easy plugin installation, each plugin (library) need one
> manifest file.
> >If plugin implement one collation don't necessary mean that
> it implement the charset.
> >
> >I think should be something like this:
> >
> >[charsets]
> >win1251
> >win1252
> >iso8859_1
> >
> >[collations]
> >win1252:win_ptbr
> >iso8859_1:pt_br
> >other_charset:some_collation
> >
> >
> Do you have reason why this should be a totally different
> format from everything else in the system?
>
> We should have a single meta-syntax for configuration
> information. I know it is traditional in the Unix/Linux
> world to invent something new and different everything the
> opportunity presents. Look at Samba, Apache, etc. All
> different. This is, in fact, not clever, but incrediable stupid.
>
> You have chose the format that Microsoft abandoned a dozen
> years ago.
> Could you explain exactly why a collation description has
> more in common with MSDOS that say, for example, Firebird?

Jim, let me turn the problem around.
Reading such on-the-fly format is 10 lines of code and since it is
tailored for particular task it is compact and easy to edit by the user.

Various systems use XML for manifests and configuration due to the
following reasons:
1. It is readable and, more importantly, writable by any third party
system
2. Handling of non-ASCII characters is very well specified for XML
3. There are standard means to describe its format and validation rules:
XSD, DTD, etc.

None of these issues are addressed in Vulcan meta-syntax to the best of
my knowledge.
Why should we standartize of it then?

Moving further, we can bring in Xerces-C++ parser without significant
change of Firebird footprint. It uses Apache license which is compatible
with just about anything.
Xerces-C++ uses the same standard IBM ICU library for XML encodings
handling which we use in INTL anyways. The rest is XML syntax and
DOM/SAX handling which is quite compact there.

Nickolay