昔からJavaで設定は書いていました

　プロパティファイルを使う前は、もちろん設定情報のようなものはJavaクラスで表現をしていたはずです。だから、本質的にLiQ Containerは存在価値があります。

　「LiQ Container:ツールと記法の問題について」に対して、あまり「LiQ Container」を理解しないまま下記の内容を書いていますが、ターゲットを整理してみてもらいたいという要望からコメントをしてみました。もう議論しつくされているのかもしれませんが。

　環境依存の情報をプログラム内から抜き出して、運用者や利用者がアプリケーションの動作を変更するために、プロパティファイルなどが必要だったのですが、これを置き換えるものとしてXMLファイルが採用されるようになったのはなぜでしょうか？

　大きくは文法が単純で普及しやすそうだったというのがあるでしょう。運用の視点から考えると、アプリケーションの実装言語によって設定用記述言語が複数あるのは負担なのです。XMLを採用すれば、どんな実装言語でも同じ設定ファイルを利用できる、という点が重要なのだと思います。編集面での負担については、XMLエディタを使えばそれほど設定ファイルを作成するのは大変ではない、という意見に賛成の立場です。

　それで、たぶん運用側で現在問題になるのは、たとえばバーチャルホストの設定をするのにあたって、ApacheのHTTPサーバで設定する場合の記述とTomcatのWebコンテナで設定する記述が違う、ということでしょう。XMLで記述できる標準フォーマットがあってもよさそうなのに、アプリケーションで記述方法がちがうのでみんな苦労して設定方法を調べています。共通部分についてフォーマットが決まっていたら、ずいぶんと楽だろうに、というのが正直なところです。このあたり、サーバの設定などについて、Javaだけでなく他言語で実装されているサーバについて、XMLが使われるようになると、ずいぶん評価は変わってくるかと考えています。Java + XMLはすぐに普及しましたが、C/C++ + XML などは過去の資産の関係もあり、普及はこれからではないでしょうか。しかし、Ruby, PythonなどはXMLにも十分対応していると思うので、設定ファイルにXMLが使われていくことになると思います。

　さて、運用側の視点からはXMLの採用が増えていくのではないか、と意見を書きましたが、RADの視点から考えると変わってきます。プログラマの負担を減らすという意味から、採用している言語と同じ文法で、設定ファイルもかけるようになるというのは便利ですし、良いと思います。ただし、その場合の問題点は、運用サイドに対して、どこまで受け入れられるか、という点だと思います。設定ファイルの記述が従来のものと対して変わらないという前提が必要になってくるわけです。

　設定ファイルの記述方法が、ちょっと癖がある程度ならいいですが、実装言語の文法に対して深い理解が必要だと問題です。運用者に対して、シェルスクリプト、AWK、Perlといったスクリプト系（延長線上にはECMA Script, Python, Rubyも含まれるでしょう。）を理解する技能を要求するのはまだわかりますが、Javaまで使える必要があるということになると、かなり大変そうです。そもそも、設定ファイルを記述するのに、言語の数だけ覚えないといけない、というのはナンセンスです。アプリケーションの移植性も問題になるでしょう。

　なお、言語系で最も普及していると考えられるスクリプトはECMA Script になりますから、普通に考えると「普及すると仮定するなら、XML + ECMA Script」のような気がします。これならWindows系のプラットフォームでも問題なさそうですし。

　もちろん、スタンドアローンアプリのようなもので、ユーザには別途UIで設定を支援し、直接ファイルを編集することがあるのは開発者だけ、というようなアプリケーションであればプログラム言語の文法を採用するのは意味があります。ユーザにみせないところまで、ユーザにとって編集しやすいかどうかを気にする必要はありませんから。

　あとは、Java6からはJavaコンパイラをJavaプログラムから呼び出すこともできるようになっているので、コンテナで提供する利点はどこらへんにあるのか、を知りたい気がします。

　最後の方は整理がついていなくて、書きなぐりとなってしまいましたが、意見というか感想というかを書いてみました。