...MarkMailはこれだけでなく、より多くのことを提供します。MarkLogicは、700を超えるオープンソースメーリングリストにわたり約550万のメールメッセージを格納しています。Apache、MySQL、Mozilla、およびPHPリストのすべて、およびその他いくつかのリストがいずれ追加されるとのことです (すぐに実現されることを望みます)。また、インターフェイスはGoogle検索よりも優れており、同等またはそれ以上の速さを実現します。しかしさらに重要なのは、データマイニング機能を組み込むことができることであり、従来のメールシステムにもこの機能を取り入れることになると私は信じています。MarkMailが真価を発揮するのは、大量のメールアーカイブの管理にあります。そして、それはもちろん、MarkLogicがMarkMailを無料で提供した理由です。MarkLogicは、採掘 (検索) したい膨大なメールアーカイブを抱えている潜在的な法人顧客がいることを知っています。そして、既存のシステムの性能 (インターフェイスは言うまでもなく) は水準に達していないだろうこともです。
InfoQはMarkLogicのJason Hunter氏と一緒に、現在の詳細と未来の発展の方向を探求するために腰を据えて話し合った。
XMLコンテンツサーバーについて馴染みがない読者のために簡単に説明してくれますか?
XMLコンテンツサーバーは、(データ用に構築されたデータベースではなく) コンテンツ用に構築されたデータベースです。コンテンツは、テキストで、階層的であり、そして一般的に繰り返し構造がなく、XMLで頻繁にエンコードされます。例として、本、記事、Webページ、ブログエントリ、、電子メールメッセージなどがあります。我々は、商用XMLコンテンツサーバーのMarkLogic Server上にMarkMailを構築しました。MarkLogic Serverにはトランザクションストアがありますが、テーブルで考えるのではなく、XMLで考えます。MarkMailでは、すべてのメールがXML文書として表され、保存されます。テキスト検索、ファセットナビゲーション、分析クエリー、およびHTMLページレンダリングはすべて、何百万ものXML文書に対し単一のMarkLogic Serverマシンによって実行されます。
なぜXMLは電子メールにとってRDMSよりも適した形式なのですか?
私はかつて、リレーショナルデータベースをベースとしたメール検索システムに取り組んだことがあるため、電子メールの性質からして、それが実に難題であると断言できます。電子メールは乱雑です。テキストで、不規則で、階層的です。それは、従来のリレーショナル中心のデータベースに挑戦するものです。
メールヘッダーは非常によく構造化されていますが、完全ではなく、どのフィールドにも固有のサイズキャップがありません。メール本文自体はフラットなテキスト (いわゆる非構造化) のように見えるかもしれませんが、実際はそれだけではありません。パラグラフ、ネスト化された引用ブロック (人物Aが人物Bを引用する場所)、最初の挨拶、終了フッターがあります。また、添付ファイルがあり、その内部にはページやパラグラフといったものが存在し、すべて階層的に配置されています。
MarkMailでは、すべてのメールをXML文書としてMarkLogic Serverにロードします。これはメールにとって非常に自然な形式です。ヘッダー、本文パラグラフ、引用ブロック、挨拶、フッター、およびすべてをマークアップします。添付ファイルやその内容もです。その後、XML認識クエリー言語としてXQueryを使用して、構造を使用するアプリケーションを構築できます。
我々は、多くの目的で内部XML構造を使用します。たとえば、基本的な検索を実行するとき、すべてのボイラープレートフッターテキストを除外します。何のためにフッターテキストがあるかを認識しているから、除外が可能なのです。
もちろん、フッターテキストを含めてもよい場合もあります。実際、検索サービスのように、フッターテキストだけを含める場合があります。あなたが我々に人の名前を提供し、我々が署名フッターを抽出することでその連絡先を見つけ、直近のものを一番上に表示するサービスを想像してください。これができるのは、メール本文の構造 (不規則で予測できないが存在する構造) と、誰がメールを投稿していつそれが送信されたかを我々に伝えるメタデータの構造 (より規則的だが完全には予測できない構造) を混合できるからです。
別の例が、opt:noquote検索オプションです。これは、引用されたテキストではなく、オリジナルのテキストのみでテキスト一致を探したいことを示します。では、次の検索を例にとってみましょう。
"godwin's law" opt:noquote
送信者が「godwin's law」というフレーズを書いたメールが検索され、送信者が他の誰かが書いたフレーズを引用しただけのメールは除外されます。我々はメールの引用構造を確認できるので、これは簡単です。メールメッセージを表示する際にそれらを色分けするためなど、他のことにも引用構造を使用します。
別の例としては、添付ファイルの取り扱いにおいて構造を使用します。次の検索を試してください。
extension:ppt axis
PPT拡張子を持ち、何らかの形でaxisに関係する添付ファイルを含むメールが検索されます (Apache Webサービスプロジェクト)。我々が、どの添付ファイルに「axis」という用語のヒットが含まれるかだけでなく、いくつのスライド上に含まれるかや、ヒットを含むスライドに下線を引いた添付ファイルをあなたがいつ表示したかまで把握していることに、あなたは気付くでしょう。それがすべて可能なのは、構造化されていないように見えるものでも実際は多くの構造があるからです。
MarkMailの開発において、MarkLogic Serverについて学んだ最も興味深いことは何でしたか?
MarkMailの開発時に、我々は少し既成概念の枠を超えて、Javaや、Ruby、Python、Perl、および従来のWeb言語なしのサイトを構築することを決めました。代わりに、W3C (World Wide Web Consortium) によるXML中心の言語、XQueryを使って開発しました。標準的なWebベースのJavaアプリケーションの仕組みを考えてみてください。あなたのデータはリレーショナルテーブルにあり、物事をオブジェクトでプログラミングし、オブジェクトをWebブラウザ用に構造化されたHTMLに変換します。これには二重のインピーダンス不整合があり、痛みを伴います。その痛みを取り除くことを約束するため、毎月新しいORMツールとWebフレームワークが開発されています。
XQueryを使用することで、我々はすべての層で統一されたXML中心のビューを維持しました。モデルは、メールを保存する数百万のXML文書です。コントローラは、XMLに対するネイティブサポートを持つXQueryです。ビューは、メールまたはメールフラグメントを変換してXHTMLを生成できるXQueryライブラリのセットです。
開発の過程で発見した結構な役得の1つは、レンダリングされたノードが「生きている」か、依然としてネイティブ配置とつながりがあると、すべて順調になることです。したがって、私がレンダリングライブラリに「さぁ、メールからこのフッターをレンダリングしなさい」と命じた場合、それはツリーを上り、日付、送信者、件名、または必要なあらゆるものを検索でき、さらには送信者の最新のフッターであるかどうかを確かめるためにクエリーを行うこともできます。あなたは「死んでいる」データと対話する場合、ビューロジックに、必要とされるかもしれないすべての情報を渡す必要があります。良さそうですが、時間とともにそれは変化し、あなたは「ハンドシェイク」を調整しなければなりません (あるいはより一般的なのは、必要なデータを提供することが難し過ぎるためにビューが本来処理できることを処理しません)。計算に高い費用がかかるもので、それがビューによって*たまに*しか必要とされない場合、あなたはどうしますか。毎回、代価を払いますか? いいえ、たいていは、選択的に見逃すことをふと考えるでしょう。私はその件についてもう心配する必要がなくて嬉しいです。
もちろん、我々が純粋なXQueryを使って開発した基本的な圧倒的な理由は、混合したコンテンツ (例に挙げたメールなど) はXML以外で表すことが非常に困難であることです。したがって、モデルはいわばXMLであることを必要とします。私はJDOMが大好きですが、XMLに対して機能するコントローラを記述する際にJDOMはXQueryの代用としては弱いです。あなたのモデルがXMLであり、ビューがXML (xhtmlとして) を生成する場合、モデルを取り出してビューを生成するために使用する言語もXML中心であると最適です。
MarkMailは検索時にさまざまな分析ビューを提供します。何が現在のビューを駆り立て、何が将来の拡張に関して提案されていますか?
我々は、人々がただコンテンツを検索したいのではなく、コンテンツと対話することを望んでいるのだと信じています。干草の山の中の針 (のように見つけ難いもの) を見つけたい時もあれば、干草がどのようなものか確認したい時もあります。または、単に色々と見てみたいだけの時もあります。ヒストグラムによって、人々は自分がどこにいて何を見ているかを確認することができます。また、一部の人が「集団的知性 (collective intelligence)」と呼ぶものの傾向を見抜いて探求するための優れた方法でもあります。
ある話題の議論は上昇傾向でしょうか、下降傾向でしょうか? 議論は行ったり来たりしているでしょうか? それにパターンがあるでしょうか? 面白い例として、「javaone」を検索してください。毎年会議の月あたりに急増していることに気付くでしょう。また、あなたがどう思っていようと、その議論は、前年より、特に2006年に増加していることが分かります。
MarkMail分析で次に起こることは何か? それは、チャートとの対話、新しいチャート、および新しい視覚化 (ビジュアライゼーション) です。それは、私がすぐに取り掛かれるほどに具体的です。
WebサイトはAjaxを大いに利用しています。どんなフレームワークを検討し、そして実際に取り入れたものを選択した理由は何ですか?
あらゆるニーズを満たし、望んでいるすべてのウィジェットを提供し、すべてを非常に簡単にする、容易に入手可能なAjaxフレームワークを見つけた、と言えたらいいのですが。実際は、低レベルのAjaxインタラクションにMochiKitを使用しましたが、ほぼすべてのウィジェットを独自で開発しました。左/右のスライド、ファセット選択ボックス、サムネイルポップアップビューア、および対話式の結果一覧、すべて当社が独自で開発しました。
実装が最も難しかったUI機能は何ですか?
「結果セット」と「スレッド/メッセージ」ビュー間を移動する際の左/右のスライドは、何度か試行を重ねてやっと実現しました。これは、左/右のスライドを機能させるマジックを発明したRyan Grimm氏による裏話です。「結果セット」と「スレッド/メッセージ」ビュー間を移動する際の左/右のスライドは、何度か試行を重ねてやっと実現しました。これは、左/右のスライドを機能させるマジックを発明したRyan Grimm氏による裏話です。
そこで次に私は、この精巧なCSSレイアウトを忘れるように言い、テーブルベースのレイアウトを試みることにしました。1つのテーブル行と3つのテーブルセルの表を、各セクションに1つです。私は単にテーブルの位置を調整したかったのですが、これについて考えてすぐに、前の2つの解決策を1つに結合できることに気付きました。
したがって結局、3つのコンテンツdivすべてを1つのメインdiv内に配置しました (メインdivのidは'please'です。これがうまくいくことを心から望んでいたからです)。その後、'please' divの左マージンを調整することによって、私は3つのdivすべてを同時にスライドさせることができました。
このスライドトリックの副作用の1つは、ブラウザをユーザーがリサイズする際に何をすべきか考える必要があることです。ユーザーがブラウザを大きくする場合、我々はいくつかの調整を行う必要があります。検索結果divの幅を調整して、メッセージdivがビューに潜入しないようにする必要があります。これに取り組んでいるとき、最近のディスプレイは3つの列すべてを表示するのに十分な幅の広さであることに気付きました。そのため、リサイズする際に、ユーザーのウィンドウが3つの列すべてを表示するのに十分な大きさであるかどうかを定期的に確認しています。
私はどのスライド列の表示も調整しません。それらはすべて依然として表示状態 (単にオフスクリーン) であり、コンテンツの幅は実際には変化していません。」
公開サイトではまだリリースしていませんが、我々はスライドよりも高度な技術を必要とする1つの機能を開発しました。それは、複数の検索用語ヒットがあるメールメッセージをより読みやすくする、新しいレンダリング手法です。それについては世間に発表してから喜んで詳しくお話します。
MarkMailの将来のバージョンについてどんな計画がありますか? あなたは、ほとんどのオープンソースメーリングリストのアーカイブに関して、MarkMailはGManeやNabbleと競争関係になると思いますか?
GManeはニュースゲートウェイに対するメールとして設計されたもので、メーリングリストをニュースフィードとして表示したい人にお勧めです。Nabbleはフォーラムの主催に大きく貢献するため、フォーラムを主催したい人にとって優れた場所です。MarkMailでは、検索、分析、および性能に焦点を合わせています。コミュニティが過去の履歴からさらに多くの物を得られるようにすることを、強く重視しています。開始以来200万以上のメールをロードしており、オープンソースプロジェクトおよびその他の両方について、今後もさらにメーリングリストをロードし続けるつもりです。現在600万にも達しています。当社はコミュニティの要求に基づいてロードの優先順位を決めるので、ご自分のリストを追加してほしい方は、http://markmail.org/docs/feedback.xqyからその旨をお知らせください。
原文はこちらです：http://www.infoq.com/news/2008/01/markmail