ベールを脱いだLonghorn（2）

画面4●WinFSに登録された画像は自動的にグループ化される 日付の範囲（a）や，画像データの大きさ（b）でグループに自動的に分けられる。こういったビューはユーザーが切り替え可能だ。

リスト6●Contactsフォルダを操作するプログラム 新しいアイテムを追加するプログラム例。対象はデータベースだが，よくあるオブジェクトのコレクション・クラスなどを操作するのと似ている。フォルダとアイテムという関係で整理していることが分かる。

画面5●アイテムの追加とアイテムの一覧 画面上部はアイテムを追加する部分。下部でアイテムの一覧を表示させている。

リスト7●アイテムの一覧を取得 フォルダ・オブジェクトを取得し，そのなかにあるアイテムをすべて取得するという手順である。

画面6●ルートフォルダのアイテムの一覧 アイテムがファイルに変わっていることがわかる。同じプログラミング・モデルで操作できる。

WinFS データベースが標準で付属

　Longhornの目玉と言われているもう一つが，WinFSである。WinFSはデータベースにファイル・システムを管理させようというものだ。これまでファイル・システムは，ディレクトリ構造という一つの分類軸しか持たなかった。それをもっといろいろな分類軸で管理できるようにするというのが，WinFSの精神である。ただ現状の作りを見る限り，あまりこの点については進歩したとは感じられない。ファイル・システムである以上，本来ユーザーが操作するときに，「いかに整理するか」を支援する機能を備えていなければならないが，それが見つからない。これでは中身がいかに賢くなろうとも，画竜点睛を欠くというものだ。

　ユーザーにとって目に見えるのは，スタート・メニューに登録されている「Contacts」「Documents」「Photos and Videos」「Games」「Music」の五つのフォルダである。これらはWinFS配下の領域（ストア：Storeと呼ぶ）に格納されたデータ項目を表示する仮想フォルダである。この領域とNTFSに格納されたデータには何の関係もない。例えばLonghornを使っているコンピュータのさまざまなディレクトリに格納した画像データを，Photos and Videosを通じて一覧したり整理したりできるわけではない。

　そこでまず，画像ファイルの入ったディレクトリごとPhotos and Videosのフォルダにコピーしてみた。スピードはともかく，フォルダはなくなりすべての画像が何らかの分類でグループ化される（画面4[拡大表示]）。例えば撮影日付でグループ化したり，ファイルの大きさでグループに分けることができる。ただこれらは，あらかじめ定められたスキーマに従っているだけだ。標準で用意されている分類軸に沿って分類しているにすぎない。例えば，写真に「娘の写真」という属性を付加できて，新しいフォルダとして「娘の写真フォルダ」を作る。そしてその中で日付や大きさによって分類するといったことは，今のところできないようだ。極端な話，このフォルダでは登録した画像の名前を変えることすらできないのである。もっともこれはあくまでもプログラマ向けの評価版なので，実際には変わる可能性は十分ある。また現在WinFSはNTFSの上で次期SQL Server（開発コード名「Yukon」）を動かしているので，レスポンスが非常に悪い。単に名前変更の処理結果を待ちきれなかっただけかもしれない。

プログラム的には「ただのDB」

　ユーザー・インタフェースにあまりインパクトがないなら，プログラム的にはどうだろうか。プログラマにとっては，逆の意味であまりインパクトがない。つまり，「結構フツー」なのである。

　これを検証するため「連絡先を一元管理する」Contactsを操作してみよう。WinFSでは，ファイルに相当する「アイテム」と，それを格納する「フォルダ」を使って操作する。

　まず最初に，データを登録したデータストアを指定する（リスト6[拡大表示]）。これは登録したアイテムの「コンテキスト」と呼ばれるものを作るときに指定する。特にデータストアを指定しなければ，デフォルトのデータストアが選択される。Contactsなどあらかじめ用意されているデータ形式はデフォルトのデータストアに入れられるので，そのまま指定すればよい。

　次にアイテムを格納するフォルダを指定する。Contactsに登録するアイテムは，あらかじめ用意されたよく使うフォルダ（WellKnownFolder）として定義されている。そしてそこで新しいアイテムを追加すればよい。これをプログラム化して実行すると，新しいアイテムができる（画面5上[拡大表示]）。

フォルダで識別する仕組みは継続

　実際にこれが登録された結果を参照するプログラムも作成した（画面5下[拡大表示]）。フォルダに登録されたアイテムをすべて，リストボックスに放り込むというものだ（リスト7[拡大表示]）。ここには単なる個人名のほか，登録時に指定した組織名なども入っていることが分かる。

　ここまで見て気づかれたと思うが，こういったプログラミング・モデルはオブジェクトの集合を扱う場合にごく普通のものだと言っていいだろう。しかもContactデータベースはまさにデータベースであって，あまりファイルらしくない。

　そこでリスト7のプログラムをちょっと変えて，同じデータストアにおけるrootフォルダを参照するようにしてみた（画面6[拡大表示]）。ロジックはフォルダの生成部を変えるだけである。こうするとファイルの一覧が表示される。ここから分かるように，ファイルそのものとContactのアイテムが全く等価に扱えるのだ。このあたりにファイル・システムらしさが出てくる。

　以上から分かるように，フォルダという単位でファイル（アイテム）を整理するという考え方は続いている。そして，根っこであるrootフォルダからは，Contactsなどのフォルダは見えない。この振る舞いから考えると，さまざまなデータ形式に横断的な仮想フォルダを作るには，それなりのプログラミングをしなければならないだろう。これなら普通のファイル・システムでも頑張ればできないことでもなさそうだ。もちろんアイテムに割り当て可能な属性の種類が違うので，できる範囲には限度がある。だがWinFSも，それほど突き抜けたことができるというイメージはない。つまりWinFSのアイデア自体は面白いが，この実装ではあまり魅力は感じられない。

　ここには示さなかったが，背景でYukonが動いているので，SQLを使って操作対象とするアイテムを絞り込んだり，操作することも可能である。