libchise, API, glib

[守岡知彦 / MORIOKA Tomohiko]

守岡です。浦島フォローで申し訳ありません。

>>>>> In [chise-ja : No.00210] 
>>>>>	"江渡さん" = Kouichirou Eto <2003 ＠ eto.com> wrote:

江渡さん> WebObjectsがけっこういいらしいという噂を聞いて、
江渡さん> 使ってみようかと思っている今日この頃です。

いよいよ Mac OS X でしょうか？

江渡さん> > (1) 関数 chise_open_feature_table の界面
江渡さん> > 
江渡さん> > 今は
江渡さん> > 
江渡さん> > int
江渡さん> > chise_open_feature_table (CHISE_Feature_Table **db,
江渡さん> > 			  CHISE_DS *ds, const char *feature,
江渡さん> > 			  DBTYPE real_subtype,
江渡さん> > 			  u_int32_t accessmask, int modemask)
江渡さん> > 
江渡さん> > となっていますが、
江渡さん> > 
江渡さん> > int
江渡さん> > chise_open_feature_table (CHISE_Feature_Table **db,
江渡さん> > 			  CHISE_DS *ds, const char *feature)
江渡さん> > 
江渡さん> > で良いような気がします。そういうのは data_source の属性に
江渡さん> > して、data_source 毎に設定するようにした方が楽じゃないかと
江渡さん> > 思うのです。いかがでしょうか？

江渡さん> 基本的にはいいと思います。

江渡さん> 関連しそうな話で、my属性データベースをどうするかの問題があり
江渡さん> ます。標準文字データベースはread onlyでopenし、my属性文字デー
江渡さん> タベースはread/writeでopenするという仕様がいいかなと思ってま
江渡さん> す。

江渡さん> BDBの場合、read/writeで複数のプログラムからopenするというこ
江渡さん> とはできませんよね。通常は標準文字データベースをreadとして使
江渡さん> うという前提で、このような仕様がいいのかなと思いました。

江渡さん> 具体的にはCGIでRuby/CHISEを使い、文字データベースにアクセス
江渡さん> するプログラムを作ろうと思ったのですが、複数起動の問題がある
江渡さん> だめどうしようかと悩んでました。

XEmacs CHISE における初期の外部 DB 実装では read/write で open してた
のですが、複数起動はできたような記憶があるのですが、実際の所どっちかは
判りません。

XEmacs CHISE では通常 read mode で open し、save-char-attribute-table
する時のみ write mode で open するようにしてますが、これは permission
の問題を解決するためにこうしたのでした。というのも、初期の XEmacs
CHISE 外部 DB 実装では文字データベースに対する書き込み権限を持っていな
い user は文字データベースに対する読み込み権限を持っていても読み込みに
失敗したからです。つまり、read/write で open した時に、read だけ可能な
場合に、read only で開くことができれば良かったのですが、そうならなくて、
open そのものが失敗した訳です。

でまあ、結論としては、江渡さんがおっしゃるような仕様に賛成です。という
か、read mode とか write mode とかは隠蔽して、現在の XEmacs CHISE がやっ
てるように書き込む時のみに write mode で開くのが良いかなと思います。


江渡さん> CHISE_DSが何を意味するのかわかってないのですが、
江渡さん> 標準文字データベースとmy属性データベースがあるとすると、
江渡さん> CHISE_DSが二つになるのでしょうか。それともそのような違いを
江渡さん> CHISE_DSの中で吸収するのでしょうか。

江渡さん> なんとなく前者のような気がします。だとすると、どのデータベー
江渡さん> スを使うかは、APIの利用者が自分で選択することになるわけです
江渡さん> ね。

CHISE_DS は data source（≒ CHISE 第１層の実データ）のことです。

仮に標準文字データベースが /usr/local/lib/chise/ に my素性データベース
が ~/.chise/ にあるとするなら、これは２つの data source になります。

;; 但し、こういうのを統合した仮想 data source として扱うというのは良い
;; かも知れません。でも、その場合、その仮想 data source の type は
;; Berkeley DB ではないことになります。

今の所、libchise で data source の集合を扱ったり、data source に対する
directory service みたいなものを提供することを考えてないので、どのデー
タベースを使うかは利用者の責任になります。


江渡さん> > (2) glib の利用
江渡さん> > 
江渡さん> > 気の利いたサービスを実装しようと思うと、
江渡さん> > 
江渡さん> > ・バッファ長を気にしなくても良い文字列、バイト列等
江渡さん> > ・ハッシュ表
江渡さん> > ・リスト
江渡さん> > 
江渡さん> > が欲しくなります。こういうのを自分で作るのも良いんですが、
江渡さん> > Gnome 使っている人が多いならいっそ glib を使うのはいかがで
江渡さん> > しょうか？

江渡さん> どちらかというと依存は増やさないほうがいいと思います。

確かにそうなんですけどね。

ただ、上記のものがあると、インピーダンス・ギャップが小さくなって実装作
業が気持ちよくなるかなということなんですが。


江渡さん> そのような気の利いたサービスはlibchiseの上のレイヤーで提供す
江渡さん> るんじゃなかったでしたっけ。

とりあえずやりたいのは、

(a) 素性名の名前管理・名前解決
(b) 文字列レベルの処理
(c) decoding_table/feature_table の隠蔽
    即ち、明示的に open/close せずに、feature/CCS 名等で get/put,
    decode/encode するようなサービスを提供したい
	→ feature/CCS 名に対応する database の open/close の自動化・
	   キャッシング

というようなものです。ただ、(c) は高レベルサービスという気はします。

また、(c) のようなものを提供する場合、現状の低レベルサービスもあった方
が良いのか、なくても良いのかという疑問もあります。

-- 
守岡 知彦 (MORIOKA Tomohiko) <tomo ＠ kanji.zinbun.kyoto-u.ac.jp>