■

まあ、おそらく2年後には大幅に変わっているかもしれない、Longhornに関する無駄知識。
font
AVALONはDirectX上で画像関連を処理しているため、GDIが使えない。そのため、fontをメモリの中で変換処理する必要がある（DirectX→Bitmap／GDI→TTFont）
注）Service一覧のcache serviceを参照する。このあたりはVS.NETが吸収してくれる？
MS Search
WinFSもWin32 Serviceで動いている。WinFS Serviceを再起動すると、MS Search Serviceも再起動がかかる。WinFXのSystem.Searchは、おそらくこのMS SearchのProxyクラス（？）
MS SearchはGathererとIndexerの2つから生成されているので、もしかしたらSite ServerとかMSN Searchからのアルゴリズムを継承しているのかもしれない（by 某MS社員）。
おそらく、GathererとIndexerを別のマシンで動かし、P2PでGathererの結果を集めて、自分に都合の良いIndexerを作れる仕掛けか。となるとこれもIndigoで公開されるかも。
Tcp Transport Listener Service

HTTP.SYSと並ぶKernelモードのProtocolハンドラのひとつ（？）。
W3WP.EXEはWindows 2000 SP3ではHTTP.SYSとしか繋がっていないけど、IndigoになってからはW3WP.EXEはさまざまなリスナと繋がるようになる。わかりやすい例がSMTPか。ここでWeb Serviceの受け付けとか。
WinFSSync
Windows File System Serviceのほかに動いている。このSyncは、

• 「Schema Sync」
• 「Hierarchy Sync」
• 「Content Sync」

の三段階を想定できる。このSyncこそがIndigoのMessage型Web Serviceで動く（のかな？？？）。
ExplorerのMy Computerの下に「defaultstore」というFile共有が勝手に作られる。これがWinFSの入り口じゃないかというもっぱらのウワサ。
ローカルに存在しているファイルではあるけれど、一度ファイル共有を通すことで各種フィルターの実装を可能とするという考え方をすれば、WinFSもSMB Redirectorを使ってフィルタを混ぜ込むようにしている（のかもしれないなあ）。
まあ、これだと誰が何を操作したか全部わかるからSyncの一意性も簡単に出せる。あと、内部のChain構造も自由に設定することができる。
defaultstoreの中を見ると、

• 「Schemas」
• 「 StoreInformation」
• 「SystemData」
• 「Volumes」

となっているから、ここはTemplateと考えても差し支えないかも。つまり、これをコピーすることで新しいWinFSのStackを作るという、GPOみたいな管理かね。