[Comerrers] Welcome and proposal

[Alexandra Ellwood]

>It's been a week since I sent the invitation to this list, so I figure
>everyone who's going to join, has.

On Mac OS X, we have already had to solve the problem of 
internationalization.  Unfortunately Mac OS X does 
internationalization in a completely different way than you describe. 
Each Mac OS X bundle has a default language and any number of 
additional supported languages.  For each supported language, the 
following file exists:

<myApp>.app/Contents/Resources/<Language>.lproj/InfoPlist.strings
or
<myBundle>.<bundleExtension>/Resources/<Language>.lproj/InfoPlist.strings

Bundles may also contain the following file for the default language:

<myApp>.app/Contents/Resources/InfoPlist.strings
or
<myBundle>.<bundleExtension>/Resources/InfoPlist.strings


InfoPlist.strings is a unicode file containing a list of key/value 
pairs.  Each InfoPlist.strings file normally contains the same keys, 
allowing you to look up the appropriate string for the current 
language.  All of the looking up and determining the language stuff 
is done for us by the Core Foundation API.

To support this mechanism, we have a perl compile_et which generates 
a ".strings" file in addition to the ".c" and ".h" files.  This 
strings file can be concatenated with 
<Language>.lproj/InfoPlist.strings in the application bundle.  By 
having one .et file for the default language and multiple 
InfoPlist.strings files for each alternate language, we can support 
internationalization Mac OS X-style.

Because we generate the ".c" file, our com_err library supports 
registering the C error tables (usually the one corresponding to 
English).  Our com_err library searches the Kerberos framework and 
the main bundle for the localized error string and falls back on the 
traditional C table.

Our com_err library also supports a few features which have to do 
with the way error reporting works in KfM:

We have an "error_manager" ("et_manager") tag and a --manager command 
line option which specify the name of the API whose error this 
belongs to.  This allows our Kerberos errors to say things like 
"Kerberos 5: Service expired" and "Kerberos 4: Service expired" 
instead of just "Service expired".  We do this because there is a 
substantial amount of overlap between the content of krb4, krb5 and 
gssapi errors.

We have an "error_table_base" ("et_base") tag and an --base command 
line option which specify a specific base error code rather than 
generating it from the table name.  This is because we have error 
codes in some of our APIs which can't be generated by normal com_err 
table names.

We also support the "index" tag which Heimdal uses.

>Finally, and this is out of scope but it's worth asking about, AFS has
>add_to_error_table, and kth-krb/Heimdal has 
>com_right/initialize_error_table_r;
>Do any of the other implementations have functionality not replicated in
>the others?

We use add_to_error_table.  Of course with our setup, you don't 
actually need it.  ;-)


I suspect our implementation isn't particularly useful to anyone 
else, but I figured I'd give you a heads up since our com_err is 
going to be forced on any Kerberos-using application on Mac OS X 
because of the nature of -- arguably bugs in -- the object format on 
Mac OS X.  I apologize for that.


--lxs
-- 
-----------------------------------------------------------------------------
Alexandra Ellwood                                               <lxs@mit.edu>
MIT Information Systems                               http://mit.edu/lxs/www/
-----------------------------------------------------------------------------
--