2004年07月09日

2004/07/08

技術関連のニュースを読む機会が多くなったので、アグリゲーターでも使おうかなぁと思い、シャープリーダーNewsGlueを試すが、重い。起動が重すぎる。
ニュースはそんなに頻繁に確認する物ではないので起動が遅いのは痛い。

仕方ないので、自分で作ろうかなぁと思い始めた。
とりあえず、Borland C++Builer 6Xercesをビルド。
800万行超!うーむ、ビルド時間もすごいが行数もすごい。

寝る前にPerl & XMLを少し読む。
PerlにはRSS専用モジュールがある。って、C++用のやつもないかなぁ?と考え始める。
よし、明日探そう。

投稿者 Takenori : 05:54

2004/07/09

ニュースの各記事を保存するのに独自のデータ形式を設計して、読み込み書き込みライブラリを作って・・・というのは、ちょっと現実的ではない。
だいいち面倒臭すぎる。
XMLを使って保存することも考えたが、こういうことは明らかにRDBMSの方が向いている。
たぶん、XMLでやってしまうと、記事が多くなってきた時、読み込みが遅くて嫌になるだろう。
そんなこんなでRDBMSを使うことを決めたが、まだ何を使うか決めていない。
とりあえず、MySQLかなぁと思ったが、そんなことしたら一般配布が困難になってしまう。
別にいいかと思いつつBCCでMySQLにアクセスする方法などを調べてみる。
データベース操作実験と言うページがよさげであった ( MySQLではないが ) 。
その後、直接プログラムに組み込めるDBがあるのではないかと気づき、調べたところいくつか見つかった。
そのような用途ではDBM, NDBM, GDBMなどが有名なようだ。
しかし、最近はBerkeley DBがよく使われているような感じだ(自信なさげ)。
このブログもBerkeley DBを使っている。
と言うことで、Berkeley DBを使おうと決めるが、使い方など全く知らないので、調査したところ、Berkeley DB で遊ぼう!と言うページが良さそうな情報を提供していた。

RSSを扱うのに特化したライブラリやコンポーネントがないか探すが見つからず。
Xerces-C++を使って作るか。

投稿者 Takenori : 06:05

2004年07月11日

2004/07/10

Berkeley DBで遊ぼう!を読んだが、良い、シンプルな作りだ。
でも、C++の方は載っていない。
で、ググるが良さそうなページが見つからない。
DLしたBerkeley DBのドキュメントを見てみる。
各APIの説明などは ( 英語で ) 載っているが・・・
これはいきなり作るか。いつも通り。
よし、サンプル見ながらいきなりゴリゴリ行こう。

投稿者 Takenori : 01:07

2004年07月12日

2004/07/11

とりあえず、DLしたBerkeley DBをVC.NET 2003でビルド。
エラーが出るが、tcl(2)やjava用の何かのようなので気にしないことに。
ライブラリはきちんと出来ているし。
でも、このライブラリBorland C++ Builderで使えるんだろうか?
たぶん大丈夫だろう。
COFF(2,3)、ELF(2,3,4,5,6)、PEフォーマットなどで出来ているだろうから ( すごい自信なかったり ) 。

投稿者 Takenori : 01:36 | トラックバック

2004/07/12

Berkeley DBライセンスをチェック。
オープンソース形式なら無料、ソースを公開しない場合は有料です。って事らしい。
オープンソース形式とは、GPLとBSDを含むopensource.orgで記載されている条件を満たした物らしい。
オープンソースライセンスは@ITによる解説文GNUによる解説文がわかりやすそう。
次に添付されていたライセンス文を読む。
Berkeley DBのソース配布予定はないので、バイナリ形式の項を読む。
バイナリ形式で配布する場合は、上述のコピーライトの複写、この条件リストと以下の免責条項を配布物に付属するドキュメントもしくは他に付属する配布物に添付すること。
免責条項の欄はまだ読んでいない。

注意!!上記解説は私のつたない英語力で読解した物なので、当てにしないで下さい。
この解説を元に損害を被っても私はいっさい責任を負いません。
と、一応書いておこう。

で、どうするかだが、派生物の定義が微妙だ。
Berkeley DBのDLLを使用したソフトウェアは派生物になるかどうか。
GPLの場合、リンクするソフトウェアは派生物とされているが、LGPLの場合は、派生物ではないとなっている。
Berkeley DBのライセンスはどうなのだろう?これはかなり詳しく追いかけていかないとわからない問題だ。
とは言っても、このアグリゲーターはフリーで良い物が見つからなかったので、作ろうと思った物だ。
なので、オープンソースにしてしまっても問題ない。
とりあえず、オープンソースで行くことにしよう。
しかし、今後Berkeley DBを使ったソフトウェアを開発する時はどうするか?
オープンソースではなくプロプライエタリなモデルを採用したい場合だ。
うーーん、購入すればよいか。

その他発見したBerkeley DBに関するリンク
Berkeley DB と mmap
UNIX DBM掲示板
等を発見。
他にもいろいろと読んでみたが、良さそうなドキュメントは見つからず。
AmazonでもBerkeley DBの書籍を探すが見つからず。
やはり、添付ドキュメントとサンプルソース見ながらゴリゴリしかなさそうだ。
でも、当たり前と言えば当たり前だが組込型のデータベースはBerkeley DBが一概に最良というわけではないようだ。
まあ、面倒なのでBerkeley DBでいいや。

投稿者 Takenori : 04:08

2004年07月26日

2004/07/26

少し前にSQLiteと言うものを知った。
SQLiteはRDBのような使い方をする用途ではBerkeley DBに取って代わろうとしているとかしていないとか書いていた記憶がある。( 残念ながらそのページのURLはメモするのを忘れていた )
で、調査することに。
パブリックドメインで、自由にコピー、変更、出版、使用、コンパイル、販売、オリジナルSQLiteのコードの配布がバイナリ、ソースコード問わず、どのような用途でも、商用、非商用関係なくできるようだ。
詳しくはこの文章を呼んで下さい。

注意!!上記解説は私のつたない英語力で読解した物なので、当てにしないで下さい。
この解説を元に損害を被っても私はいっさい責任を負いません。
この文再び登場。

すごい。すばらしい。
なんて崇高な思想なんだろう。
しかも、SQL文が使える。まあ、そのせいで動作はBerkeley DBよりは遅いことが予想されるが、ベンチマークを見る限りでは、MySQLと同じか少し速い、PostgreSQLより圧倒的に速い。
速度的な問題は実際にアプリに組み込んで使ってみないことには何とも言えないが、たぶん大丈夫だろう。(根拠なし)

簡単にコマンドラインのプログラムをいじってみたが、いい感じだ。
普通のRDBMSのような感じで使える。
しかも、データはファイルに直接書かれる。
クライアント・サーバ形式ではない。
ああ、素敵だ。
もう、SQLiteに決めた。(即決!惚れた!)

現時点ではバージョンの問題があるようだ。
2.8系と3.0系。
3.0系は次のバージョンで安定版になるだろうと書かれている。
どうするかなぁ・・・
3.0系にするか。
BLOBをきちんとサポートしているし、UTF-8、UTF-16もサポートしているし。
何より新しい方がいい。
全く持っていい加減だが、気にしない気にしない。

結果
データ保存部分はSQLite V3.0系にする。

ラッパーとしてこれが有用かも。

投稿者 Takenori : 04:52

開発凍結

フリーで良い物がないと言うことで開発を始めたアグリゲーターだが、今日なかなかよさげなのを発見したので、凍結することにした。
当面は開発前の調査中に得た情報 ( このブログの開発日誌 ) を整理して、今後のために保存する作業を行うことにする。

投稿者 Takenori : 06:17

 
Total : Today : Yesterday :