From owner-freebsd-config Wed Jan 22 05:37:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA04908 for config-outgoing; Wed, 22 Jan 1997 05:37:56 -0800 (PST) Received: from lenlen.mt.cs.keio.ac.jp (lenlen.mt.cs.keio.ac.jp [131.113.32.126]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA04903 for ; Wed, 22 Jan 1997 05:37:51 -0800 (PST) Received: (from hosokawa@localhost) by lenlen.mt.cs.keio.ac.jp (8.8.4/8.8.2) id WAA24186; Wed, 22 Jan 1997 22:33:00 +0900 (JST) Date: Wed, 22 Jan 1997 22:33:00 +0900 (JST) Message-Id: <199701221333.WAA24186@lenlen.mt.cs.keio.ac.jp> To: msmith@atrad.adelaide.edu.au Cc: davidn@unique.usn.blaze.net.au, jkh@time.cdrom.com, keithl@wakko.gil.net, config@freebsd.org, hosokawa@mt.cs.keio.ac.jp Subject: Re: Kernel configuration In-Reply-To: Your message of Wed, 22 Jan 1997 17:23:24 +1030 (CST). <199701220653.RAA14007@genesis.atrad.adelaide.edu.au> From: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) X-Mailer: mnews [version 1.19PL2] 1996-01/26(Fri) Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Removed -chat.... In article <199701220653.RAA14007@genesis.atrad.adelaide.edu.au> msmith@atrad.adelaide.edu.au writes: >> Thankyou 8) I've been using that style of syntax in our current software >> for about 18 months now (in case you were wondering whether I'm just >> making this up as I go along 8), and it's proven to be very useful. At first, I thought that using SGML is better for maintaining this system's extensibility because we can easily and intuitively extend the syntax by modifying DTD, but now I think there're no apparent difference in maintainance cost between SGML, Lex/YACC, Tcl, Perl, etc. because we also have to extend the system not only in syntax level but also in semantic level. >> You could group based on the file the options are defined in, or you >> could add a 'group' attribute, perhaps even with a heirachial syntax >> if you thought it was worth it. I'm sorry if I'm misunderstanding your statement, but I think that heirachical syntax introduces the same problem we have experienced in Pascal :-). For example, If A relys upon B: B { A { } } .... it seems to have no problem, but if A relys upon B and C, and the relationship between B and C is peer, it's impossible to be expressed in this syntax. I think that the relationship between options and devices should be acyclic graph, not tree. >> That actually sounds fairly reasonable. In situations where >> only english text was available, the tool could fall back >> on that as a default. (eg. I distribute a new driver with a .ki >> file but not a .kim (message translation) file) I implemented I18N extention to sysinstall (currently supports Japanese and Traditional Chinese (Hong Kong and Taiwan)). This system uses English message if there are no corresponding I18N messages. If somebody wants to extned the sysinstall, s/he don't have to worry about I18N support. There's another problem to support I18N in such file is editors' capability to mix many encoding system in single file. For example most editor that can edit ISO-8859-1, can't edit ja_JP.EUC or zh_TW.big5 text in the same file. I think this problem can be avoided in the following ways: 1. Separate DESC files for each languages It's easy (and I used this way for I18N sysinstall), but readablity of files is poor, and it's hard to maintainance the consistency between languages. If we take this way, we must introduce the semiautomatic version management system that can evaluate the version of each message (by using MD5 or something) and mark "dirty bit" on unmodified I18N messages whose original English message has been updated. 2. Use Unicode Aside from the evaluation of Unicode system (this system is not loved, or even hated by many Asian people), there're no good editor that can edit Unicode documents. 3. Use MIME (or other encoding system that can map any charsets into 7-bit ascii code) This also requires supporting system to encode/decode messages in single file. Sorry I'll think about requirement and formal definition of this metacofig system this weekend because this week I'm too busy until weekend :-). If you have any good idea, please tell me. -- HOSOKAWA, Tatsumi hosokawa@mt.cs.keio.ac.jp hosokawa@jp.FreeBSD.org