Jon Udell: Groove, four years later

そう書いている裏で、Grooveの共同創業者とVPのJack OzzieとMichael HelfrichにJon Udellがインタビューしていた。アーキテクチャや技術的な話がメインとなっているが、最後のワンパラグラフが現状をシンプルにまとめている。この部分のみ引用して締めたい

最近は読んでないんだけど,Grooveの一文字を見つけた以上はユーザーとしては読まざるを得ない.

Jon Udell Groove, four years later
http://weblog.infoworld.com/udell/2004/05/04.html#a988

興味深いのでいろいろ抜粋

Sayonara, top-to-bottom XML I don't believe that I pay a performance penalty for using XML, and depending on how you use XML, you may not believe that you do either. But don't tell that to Jack Ozzie. The original architectural pillars of Groove were COM, for software extensibility, and XML, for data extensibility. In V3 the internal XML datastore switches over to a binary record-oriented database.

さよならって英語で通じるのか.
ほら さよならXMLですよ.まして今時テキストのDBにこだわるなんて原始人ですよ(笑).
続くパラグラフによると,XMLDBの進む方向がGrooveが望む方向とミスマッチになってしまったようだ.具体的にどうミスマッチになったのかは書いてないのが残念だがXPathが関係しているらしい.

Groove and .NET The managed-code interface to Groove gets an overhaul in V3 but the core product itself does not rely on .NET. Not because Groove's developers wouldn't like to use

中略

The CLR and .NET Framework aren't yet infrastructure that a mainstream Windows developer can take for granted. But when that finally becomes true, a whole lot of pent-up developer demand for .NET services will be released.

ということで.NETはサポートしないらしいが,でも.NETがメインストリームになるようなら対応するかもとのこと.

ほかにもUIを構築する言語としてVBScriptJavaScript以外の言語をつかえるようにするかとかWeb service interfaceのことなどあるが,どうも技術的には保守的な印象を受ける.

つづくChallengesがGrooveの置かれている妙な立場を簡潔ではないにしろ説明している.

"Do you want to save?" It's the classic dilemma of every document manager that hooks File Open and File Save gets in between apps and storage in order to add value. In Groove's case, that value is considerable: automatic secure synchronization, and change notification, across all instances of a shared space. But until and unless a more intimate relationship can be forged between Groove's secure/transacted/synchronized storage and the OS-level storage APIs that applications expect to see, there's just no way to make this seamless.

ぶっちゃけた話,Grooveは昔懐かしいFDとか,InternetがつかないExplorerとかNautilusなんかと同じファイルマネージャーソフトである.で普通のファイルマネージャーソフトと違うのは,上記のFDなんかのソフトがコンピューターのローカルなストレージを扱うのに対し,GrooveはSpaceと呼ばれる仮想のP2P空間上に存在するストレージを扱っている.
もちろんファイルマネージャとしての機能だけではなくて,ニュースグループみたいなディスカションの機能やPIM的な機能もある.ちなみにこれらもSpace上に構築されるのである.
ここまではいいのだけどやっぱ疑問が出てくるのだ.つまるところGrooveはP2Pストレージ空間を構築する機能と,そのP2Pストレージ空間にアクセスするU/I機能がペアになっているのだが,これはP2Pベースじゃないといけないものなのだろうか?
要はネット上にSharableな仮想空間を作って,その空間にアクセス出来ればいいのであって,その実現方法はP2Pにこだわる必要はない.それどころかP2Pベースにしてしまうと,P2Pクライアント側が重くなってしまうという問題がある.
むしろクライアント側はU/Iだけのクライアントにして,それ以外の機能はネットワークというかサーバー側に持っていたほうが筋がよいのではないか?
いやオフラインとかネットの信頼性の問題があるのかもしれないが,これからの世の中というか既にPCは電気とネットがなければただの箱で,オフラインはありえないと考えたほうがよいのではないだろうか.
そういうわけで僕はP2P技術は

SNSも含めて全てネットワーク側に吸収されていくシナリオをメインとしつつ、役割が無くなっていってしまうのだろうか。

という方向にいくと思っている.
Winnyの件でP2Pという技術の芽が絶たれると騒いでいる人が多いけど,P2Pはもはや匿名情報共有くらいにしか使いようのない技術で,まともな使い方の芽は既に絶たれているのである.
もちろんこれはエンドユーザーベースの話で,P2Pストレージとか面白そうなネタはあるけど,エンドユーザーに,これはP2Pで実現されていると意識させるような形で発展する可能性はないだろう.
あとはゲームくらい?でもこういうアドホックネットワークはP2Pと呼べるのかな?


[permalink][contents][page top]