Takuro Ashie
ashie****@homa*****
2003年 10月 20日 (月) 04:02:49 JST
足永です． > KzRSSやKzLIRSオブジェクトを捨てて > KzMETAオブジェクトの中でファイルをフェッチしてきた段階でファイルの先頭を > 見て、RSSなのかLIRSなのかを判断し、それぞれのパース処理にふる 基本的な方向性としてはその方が良いので，とりあえずcommitして頂けますか? KzBookmark的には問題ありません． コード的には，改善の余地があると思います． と言ってもほとんど好みの問題だとは思いますが，もう少し将来の拡張を考慮 した構造になっていると良いかと思います．(検出用のコードや kz_hoge_parse_from_stringを直接kz-meta.cに埋め込むのでは無く，関数ポイ ンタを通して呼ぶようにする) 「拡張性」という点からもう一点言及しておくと，本質的にはCで書く必要性 すらなく，本体側では一種類のフォーマットだけに対応し，残りのフォーマッ トに関しては，標準入出力経由なりファイル経由なりで外部スクリプトに渡し， そちらで本体がパースできる形式に変換して返せば良いだけの事ですよね． その方が文字列処理が遥かに楽になりますし． ただ，外部スクリプト(あるいは風博士に直接処理系を埋め込んでも良いので すが)にしてしまうと処理系の起動コストがかかって若干重くなる，実質的に 依存性が発生する等の問題があるので，well knownなフォーマットに関しては Cで対応しておくのは良い事だと思います． その上で外部スクリプトによる拡張性も確保しておけば，ユーザーが自分自身 で比較的楽に新たなフォーマットを追加する事もできます． ファイルのfetch部分も，同様に拡張性が確保されているとなお良いと思います． > 最初、LIRS対応するときは、オブジェクト思考に取り憑かれてて仮想関数だああだ > こうだやってましたが、今となってはそれぞれ独立したオブジェクトである必要が > ないような気がしてます。 ここで注目すべきは，KzBookmarkで全てのプロパティを単一の表現に統一し (これまでは，例えばKzBookmarkのlinkに当たるプロパティが，KzRSSでは rss_link，KzLIRS等ではantenna_uriという具合に，(UI側での扱いが)本質的 に同一のプロパティが別々の物として扱われていた)，一つのモデルですべて のタイプのリモートブックマークを表現できるようになった，という事だと思 います． であるため，KzRSSやKzLIRS等が独立のオブジェクトである必然性が無くなっ た，という事です(であるからこそ，当初からブックマークの抽象化にこだわっ ているわけですが)． ちなみに，今，私が悩んでいるのは，「KzBookmarkとKzMETAは統合すべきか?」 という点です．当面は今のままの方が都合が良いのですが，将来的には統合し たほうがスマートになるかもしれません(ならないかもしれません)． > ただ、自動判別といってもかなりいい加減でRSSなんかは > if (strncmp(buf, "<?xml", 5) == 0) > しか見てません(汗。 もうちょっとだけ頑張ってもらえると嬉しいかも(わら 極端な話ですが，リモートのXBELを取って来るような機能が追加される可能性 もあるわけで．
