Samba TeamのAndrewさんと会合」

各位

2001年7月18日
日本Sambaユーザー会

Samba TeamのAndrew Tridgellさんの突然の来日で、緊急にミーティングを開催しました。

日時：2001年 07月 18日（水曜日）17時00分〜22時00分

参加者:

Samba Team	Andrewさん
VA Linux Japan	鴨志田さん
Samba-JP
	小田切さん
	たかはしさん
	根津さん
	武田さん

内容

• 現在のHEADブランチで、Andrewさんが作っている簡単なテストプログラムのデモと実行結果、テスト内容について見せていただきました。
• たかはしさんが検証用にja版で使用しているテストプログラムのデモと実行結果、テスト内容について説明し、一式をAndrewさんに引き渡しました。
• 現在のHEADブランチのmake方法や使用するライブラリ環境について、聞きました。現在のところでは、フリーの実装のlibiconv 1.7を使って、UCS-2 Little Endianのモードでwireが実装されているそうです。
  (なお会合当時の実装は Endian に関する致命的な不具合がありましたが、現在は解消されています)
• Andrew さんは今回の来日で、Windows 2000 Professional 日本語版のvmware環境とたかはしさんのテストプログラムを持って帰国されますので、今後のHEADブランチでの日本語環境適用度や、再現方法の説明などに費やされる時間は相当圧縮できるようになると思われます。
• ANSI-C 未対応コンパイラの古いシステムのサポートについては、現在のja版と元の2.0.10とのソース比較をその場でしながらの細かい議論になりましたが、いくつかの修正は HEAD ブランチにcommitしてもいいとAndrewさんは仰っていました。

  合わせて Samba 日本語版の修正点は、大きく

  1. SWAT i18n
  2. 文字コード変換回りの問題の修正
  3. Tuning (trim_string / KANJI code table lookup など)
  
  に分類できるというあたりを説明しました。
• name mangling問題については、日本の独特のLFNを利用する文化の違いを説明した上で、最悪１／２０だぞという話をしました。これについては、例の新しい仕組みtdb をグローバル、かつ、スタティックに用意して、NTと同じようなライフタイムでの一意性を確保する方向でHEADブランチ自身で実現する方向で考えていただけることになりました。システムglobalでひとつのtdbだと大きすぎる場合には、先頭１バイトなどでterminfoと同じような形で分割したtdbで実現するなど方法論は色々ありそうだという話になりましたが、まずはシステムglobalでmangling専用のtdbを用意するシンプルな方法での実装をさっそく検討していただける事になりました。これは、SFN/LFNのマッピングテーブルを
  1. 単純なハッシュで持つのや止めて、ちゃんとユニークになるようにする
  2. smbd グローバルに持つ
  3. マッピングは tdbファイルに保存することにより、smbd を再起動しても、マッピングが保たれるようにする
  
  ということだったと思います。Windows と完全互換ではありませんが、従来の重複してしまう問題点はクリアされます。また Windows のようにディレクトリを移動すると SFN が変わってしまうという問題がないだけ、使い勝手がよいと言えるかも知れません。

  ただし、その後の samba-technical メーリングリストの議論で、この問題に関しては VFS の側で実装することになったようです。

• HEX/CAPのサポートについては、unix charsetに対して、HEX/CAPをサポートするような任意の.soを追加する（要はVFSレベルでのインプリメントができるような）インタフェースを用意する方向で考えてみたいという回答をいただきました。

  ちょっと補足しておきますと、Samba HEAD branch は、iconv() を利用して文字コードを行うような実装になっています。そのため、CAP / HEX/UTF-Mac といった、iconv() で変換できないような符号化コードへの変換がそのままではサポートされなくなってしまいます。

  そのため、上記の議論があったわけです。

• 日本語版でよく問題になる2バイト文字の２バイト目がcase変更されてはまる問題については、HEADでは必ずUCS2の状態でcase変更するので起きないはずだという話もでました。
• コードセット関連で、NT<->NT(2000も含む）の時にwireコードはなんになるのかという話題がでました。Unicode ビットを 1 にしても、Unicode にならない文字列があるため、それに関して、Shift_JIS だと考えてよいかということです。

  発展して、SJIS と CP932 は同じか? とかいう話になって、 SJIS は、encoding method 的な観点とcharacter set 的な観点の話があって... というところまで行きましたが、ここはちょっと英語力のなさもあって、あまり理解してもらえなかったかも。

• Mac OS X の UTF-8について、現状のSambaのUTF-8の実装で対応できないこと、Normalization が起きてしまって、そのままではストアとリファレンスなど場合によって、見えるけれどアクセスできない等の問題が発生することを説明しました。
• patch は、samba-patches@samba.org に出して欲しいといってました。 こちらの方が読む優先度が高いようです。

  チューニングはHEADブランチに対するpatchでpostしてくれと、かなり強力に要請されていました。

• ドキュメントツリーの各国語ロケール対応の為の構成について質問したところ、ドキュメントの管理担当は Jerry Carterさんなので彼に相談して欲しいと仰っていました。
• smb.confやbrowse.dat等はunix charsetで書き込めるといいだろうという話をしましたが、誤解を受けた可能性がちょっとあります。
• SWATでの表示やsmbclientでの表示など、実際のunix charsetと異なるcodeset で表示をしたいことがあるので(HEX/CAPの場合など）、これの対応が必要であることを説明しました。display_printf()のようなライブラリ関数を用意していただけることになりました。
• 外字って何？機種依存文字って何？どうやってEUCにマッピングしているの？というのが話題になりました。
  また、SJIS/EUCの両方がいまだ必要な理由についての説明や、wireの文字コードについて、日本語Windows環境でのUCS-2とShift JISの関係などについて説明しました。
• SWATのi18n化の重要性についてアピールしました。AndrewさんとしてはTODOには入ってはいるものの、unix charset 等内部コードの方にまずは注力したいとのことでしたので、さらに継続してアピールする必要があるようです。

課題

• libiconv については、相性問題が発生しないように配布に含める方法なども含めて方法論を検討する必要があるねという話になりました。日本の事情で考えるとCAP/HEXをiconvで処理できるようにする方法も考えられることと、従来のcoding systemの指定をエイリアス等の形でそのまま継承できるようにしたいという思惑もあったりします。
  また、SWATの時のcatget/gettextのことを考慮すると最初からlibiconvを同梱することも検討してみてもいいだろうという意見と、libiconv自体がテーブルがたくさんある大きなアーカイブなので同梱は難しいのではという意見に分かれ、とりあえず継続課題ということにしました。

  妥協案として、Samba をリリースするときに動作を確認しているlibiconv のバージョンを明記して欲しい。また OS に iconv が実装されていても、それを無視して、外部の libiconv に含まれる iconv を利用できるようにして欲しい。と提案しました。

• 次期日本語版を2.2.x ベースでいくかHEADでいくかについては、Andrewさん的には2.2.x を飛び越えて、HEADブランチに注力して欲しいと力強くアピールを受けました。
  Andrew さんはそう考える理由として
  • Samba 2.2.x は元々過渡的なリリースであり、文字コード関連はHEADで全面的に改訂されることが決まっている。
  • すでにUCS-2化されたHEADブランチを日本語対応にしていく方が、2.2.xを最初から日本語化対応をやり直すよりはるかにすくないコストで実現が可能なはず。
  • いまからやるなら最新の物でやってほしい。2.2.x はすでにobsoluteなコードだし、いわんや2.0.x おやでとっても古いコードである。
  ということを挙げていました。
  これについて、JP側としては、一般ユーザが使ってみようと思う程度の日本語化と品質は最低限必要であると説明しました。具体的には、SWATの表示が日本語ででてこないとか、すぐにエラーになるようでは日本のユーザに使ってもらうのは難しいという話をしたところ、
  
  • HEADに注力してくれるのであれば、HEAD直下にHEAD-JPのブランチを１つあげるので、そこでSamba-JPとして日本語対応とstableな状態を作ってはどうか？
    2.2.x はすでにリリースになっているのでなかなかそういう風に簡単にはいかないよ。
  • その場合、Samba-JP側で一人、CVSのアクセス権を割り当てましょう。
  • ルールは、Jeremyが提示していたのと同じ。（SAMBA TEAMのbasic rule）
    つまり、勝手に新しいディレクトリを作ってその中にコードを追加していったりしないことや（違うバージョンになって統合ができなくなってしまうため）、HEADにmergeできるものをmergeしないでHEAD-JPだけに適用しないこと、特に効率の改善などの日本語化や、stable/unstableと異なるものについては、HEADブランチへのmergeを基本とすること（再統合の手数を減らす為）。
  • HEADブランチへのmergeリクエストは、BugTrackを利用すること。samba-technicalにパッチを投げても拾いきれない。
  との提案を受けました。
  それで日本側からみて、JeremyさんしかりAndrewさんしかりでなかなか反応していただけていない印象を持っていることを説明したところ、Andrewさんを呼び出すひみつの方法を教えていただきました。これは、HEAD-JPのメンテナになる予定のたかはしさんだけがご存じです（申し訳ありませんが、公開できませんm(_ _)m）。

  Samba-JP的には、Windows 2000に対するドメインコントローラ機能のサポートや、2.2/HEADに対するstabilityに対する懸案、HEADとしてのリリース時期の問題など検討しなければならない事項があるため、少し回答に時間を下さいということでお願いしました。
  ただし、今回のミーティングで実際に顔を合わせている事から、また、今までのSamba-JPからの窓口的存在であることから、HEAD-JPブランチをいただいた場合のメンテナとしては一番相応しいだろうという出席者の判断で、たかはしさんをメンテナにということで仮決定しました。問題ないですよね？＞みなさま

日本Sambaユーザ会ホームページ https://www.samba.gr.jp/

本件に関するお問い合わせ