binary data files

[Deborah Wilbert]

I worked as part of a team building a (very) large, multiprocess, distributed
application and was very good about isolating the user interface, and even 
within the user interface, isolating strings used from the rest of the 
presentation code... except for the error log(*). Strings which eventually 
wended their way into the error log originated in any part of the system.

Well, along comes someone who wants to translate the system into Japanese.
"A piece of cake!" was my first reaction (we had all the display tools) and
indeed, translating the user interface WAS a piece of cake... except for
the error log.

In fact, they wanted to be able to run multiple user interfaces to
a running system, some in Japanese, others in English, simultaneously. No 
problem. They also wanted to veiw the log in either English or Japanese, upon
demand. Big problem. Virtually every component had to be changed to report
errors in a binary format rather than a string format and the error log 
itself had to be maintained in binary format to achieve this functionality.
FYI, the binary format involved an error code, and various parameters
associated with the errors.

Of course, the reimplementation necessary in most of the modules was 
unnecessary... we should always have been reporting internally in binary 
format (mea culpa), even if we maintained the original log file in English.
However, (1) a binary output file format would have enforced internal binary
interfaces thus preventing the sloppy coding and (2) the binary format of
the log file was eventually necessary for multilingual access.

If you work on any serious product, you should consider keeping log-style
files in a binary format. When I started work on my project, I had no idea it
would eventually be translated into another language.



							-Deborah 


(*) well, it wasn't really an error log... it was more integral and important
    than an error log, but let's call it an error log.