PDAのコンテンツ

PDA --- にはどんな性質のデータが入るのだろう ... アレ？どっかで書いたような 憶えがあるけども、ここで整理してみたい。

PDA といってもいろいろあるけども。データをずっとPDAの中に閉じ込めておき たいということはないはず。あと、PDA だけで大量のデータを作るということも ないと思う。

あと、PDA は、network に接続して使うものだとも思う。 完全にスタンドアローンでもいいけど、network に接続する手段が別に 欲しくなる。ただし やっぱり PDA からのアクセスコストは高い... 。 ( bit 単価は安くなるかもしれないが ... 時間がかかるとか不利な面がなくならない ことを想定)

ここでは、大胆に2つの種類のデータにわけてしまう。

• 大量の コピーデータ ... 消しても オリジナルがなくなるわけではない。 コストはかかろうとも 入手不可能な状況にもならない。

• 少量のオリジナルデータ .... いまのところ 最新版は PDA にしかない。 しかし、いつかは しかるべきところに納める予定のもの。

• internet リソース --- http のプロキシサーバを PDA にもっていて LAN につないでもそれを通してみることにする。

• メール --- マスターは安心できるマシンにおくものという前提 にすれば、メールもまた コピーデータ。で、メールを httpd で見れるように しておいて、自分用プロキシサーバ経由で見るとかするのかな。

• MP3 とかのデータ、pdf や その他の資料、うーん これどうしよう。 手で整理かなぁ。なんか、プロキシサーバ というよりキャッシュサーバが 整理とか 手伝ってくれる cgi 持っていればいいのか。

こういうことを考えると キャッシュのデータってこんな使いかたができたら いいように思う

   index ファイル            データの中身のファイル
    データ A  --------------> +-----------+
                              |           |
    未使用    --------------> +-----------+
                              |XXXXXXXXXXX|
    データ B  --------------> +-----------+
                              |           |
                              +-----------+
                                   ↑ append
    新しいデータ------------> +-----------+
                              |           |
                              +-----------+

   * だいたい PDA に入る量というのは限りがある。そのほとんどをこのタイプの
     データで占めるわけだから 目一杯使えば良い。

   * 入らなくなってはじめて.. コンパクションする。

   * PDA がオフラインで使われている間は、どんどんデータが溜ることはない。
     LAN に接続されているような状況だとどんどん更新される ...
     PDA のストレージが CF だと ちょっとやばいから、どっか別のマシンに
     データを移動させることにする。

   * コンパクションがおきなければ、追加分と index を PDA に送る。
     コンパクションがおきたら全部更新。

少量のオリジナルデータをどうやって どこに返す ...

というのは、ちょっとおいておいて、ファイルは書いていくと大きくなる という概念を導入すると、block 化せざるを得ない。

そうするとそれを管理するために、 ファイルシステムがないと辛いなぁという感じはする。

ただ、ディレクトリはなくても良いかも。上のような index ファイルが あって、ディレクトリの代わりになればそれで良いように思う。

よくわからないが、PDA の中で使う便宜上の名前と、あるべきところに あるときの名前の 2 つを持つようにするとか ...

将来考えがかわるかもしれないけど。いまのところは、

PDAのコンテンツのうち 少量のオリジナルデータ というものは、Tiki のように、http を通した cgi でアクセスすべきもの であるべきだと考えている。

• もちろん それそのものでなくても良い。そういうイメージという意味。
• なぜかというと 持ち歩いているとき以外は、 端末として 他のマシンを使いたいから。PDA のデータをアクセスするために 専用アプリを作るなんてのは、考えたくないから、普通のブラウザでアクセスできる ことというのが条件。
• 今の Tiki に いろいろな 機能を追加していかないといけないが、 データの同期のための機能は 重要視している。
• 中のデータを引っ張り出すような機能 -- Tiki:Tikiのプラグイン/DumpPlugin とか Tiki:Tikiのプラグイン/SnaphtmlPlugin とか やっているのは、このことが理由の1つ。
• それとは 別に、いろんな設定を Web の画面でできないといけないだろう。 もちろん、スケジュールとか ToDo とか 便利に使えた方が良いが ... あまり重要視していない。Tiki だけで結構使えるし。

また、PDAのコンテンツのうち 大量のコピーデータというものは、 proxy を使った キャッシュサーバー上にあるべきもの だと考えている。

• PDA の proxy を通してアクセスすれば自然に溜る ... みたいな。
• もちろん、キャッシュの整理とか 検索とか... Tiki を通してできた方が良い。

他のことはもちろんできても良い。だけども、最低欲しいのは、上の2つ。

• 出先でメールを読む。--- それはたぶんできて欲しい。そういうのは、 つぎのような役割分担で良いんじゃないかと思う。
  • 実際に読むのは、たぶんブラウザの機能
  • データ蓄積は、proxy のキャッシュサーバで
  • それを検索したりアクセスするのは、Tiki で。

• こういう考え方でいくと、mp3 を鳴らしたい ... みたいなのは、
  • 鳴らす 機能はブラウザのプラグインで
  • アクセスするのは、Tiki の リンクから。
  • あれ？ バックグラウンドで 登録したものを鳴らすとかは？

現在イメージしているもの。

PDAをコンテンツを入れる箱として

• ruby と V7ベースの独立したファイルシステム と cont による疑似スレッド

からなるシステムを想定している。たぶん この箱の出入口は、network のみ。

         +---------------+     +------+
         |  FS           |-----| ruby |------ network
         |               |     |      |
         +---------------+     +------+
                               +-------+
                               |Process|
                               | class |
                               +-------+
          

FS はもっているが 閉じている。tiki を通して アクセスするのが主な目的。
永続オブジェクト？ とかの置場として見える かどうか...までは知らない。

FS の種類は2つを想定。1 つは、ruby で ファイルシステムに見えるもの V7 ベースで、できたらジャーナリングをもサポートしたい。

もう1つは、キャッシュサーバで使われるもの、ちゃんとした ファイルシステムには見えないかも。

この箱が依存する API は、

• open/close/read/write 等の システムコールレベル I/O
  • stdio は中に含む。
• それの対象となる 1,2 のファイルリソース (ただしでかい)

• malloc/free 程度の メモリのアロケーションメソッド

• TCP/IP を扱う API

程度を想定。

そして、これを作ってみる という意味で、

• ジャーナリングファイルシステム/V7を改造してみる
• 組み込みTiki の2つのページをつくった。