Opera Dragonflyの基本設計

提供: 何かしら図書館

Opera Dragonfly Architectureをローカライズしたものです。原文とは異なる表現を使ったりしています。
この記事のライセンスはCreative Commons 表示-非営利-継承 2.5 一般です。原著作者はhansstです。

この記事はOpera Japanによって公式に校正され、Opera Dragonfly の基本設計 (Japanese) - Opera Developer Communityとして掲載されました。

目次

[編集] はじめに

この文書ではOpera Dragonflyの基本設計(architecture)について、個々の構成要素(components)の挙動を見ながら詳しく説明していきます。

[編集] 基本設計の概観

(訳注、この章に表れる語句は、同記事中の解説へのリンクとなっています。)

Opera Softwareの開発ツールであるOpera Dragonflyは、デスクトップコンピューターと並び携帯電話などのいろいろな端末でデバッグができるように設計されています。

scope moduleruntime(デバッグの行われている、Operaインスタンス内のウェブページとアプリケーション:訳注、インスタンスとは起動しているOperaの各々を指し、一つの機器上で二つのOperaインスタンスを走らせることもできる)に関する情報を見えるようにしてくれる(expose)ものです。このOperaインスタンスはdebugging hostとして動き、この情報はdebugging client(訳注、この文書中ではdebuggerという語と同義で使われている)に供給(serve)されます。この情報のデータ形式はscope protocolによって定義されています。

ファイアーウォールによる問題の可能性を防ぐために、proxyがブラウザとdebuggerの間を取り持ちます。ひとつの例としては、携帯電話用のアプリケーションやウェブページを通常のデスクトップコンピュータからデバッグする場合です。

デバッグ用アプリケーションであるclientは、情報を可視化(visualize)させてユーザーがruntimeを操作できるようにしてくれます。

hostclientは別々の機器で動いていてもよく、proxyがどちらかの機器の中や別のサーバーで動いていることがありえます。

Dragonfly Overview.png

[編集] デバッグのシナリオ

デバッグには二つの基本的な方法があります。

  • 統合(integrated): scope、proxy、debuggerが同じOperaインスタンス内で動いている場合。
  • 遠隔(remote): scopeとdebuggerが別々のOperaインスタンス(例えば別々の機器上)で動き、proxyがもしあれば、そのどちらかの機器かあるいはまた別のコンピューター上で動いている場合。

[編集] 統合

典型的なシナリオはこちらです。開発者はウェブアプリケーションを普通のOperaブラウザで操作していて、debuggerは同じOperaインスタンス内の別のページ(タブ)やパネルで開いています。

Dragonfly Integrated.png

この場合、debugging hostとproxyとclientはすべて同じOperaインスタンス内で走ります。proxyはOperaによって無作為に選ばれたポートで動作し、scope moduleとdebugger自動的にこれに接続します。

[編集] 遠隔

このシナリオの例は、携帯電話用のウェブページやアプリケーションをデバッグする場合です。携帯電話は画面が小さく開発には向いていないときがあるので、代わりにデスクトップコンピュータをデバッグに使います。

もう一つの例は、ある機器上のひとつのOperaインスタンスを、同じ機器で動いているもうひとつのOperaインスタンスからデバッグする場合です。この方法は、debugging hostのクラッシュを伴う畏れのあるときに便利です。

遠隔デバッグはさらに二つの主なシナリオに分けられます。

  • proxyがどちらかのインスタンスの中で動いている場合。
  • proxyが両方のインスタンスの外で動いている場合(例えばパブリックサーバー内)。
Dragonfly Local.png

二つ目のシナリオはデバッグの行われているOperaインスタンスとdebuggerが両方ともファイアーウォールの内側で動いているときに使われます。

Dragonfly Remote.png

[編集] 構成要素

Opera Dragonflyの基本設計は以下の構成要素から成り立っています。

[編集] Runtime

ECMAScript環境ひとつひとつがruntimeです。すなわち、各HTMLドキュメントには一つのruntimeが付随します。フレームとインラインフレーム内のドキュメントはまたそれぞれのruntimeを持っています。

[編集] Debugging host

Scope moduleが有効であり、proxyに接続されているOperaインスタンスはどれもdebugging hostとなります。これは複数のruntimeを含むことができます。

[編集] Scope module

Scope moduleはOperaアプリケーションの一部です。これが有効になると、Scope moduleはproxy URLへの接続を確立し、debugging hostのruntimeをすべて調べます。その後Scope moduleは情報をdebuggerに送ります。またScope moduleは、選択したノードに対するDOMをダウンロードするといった、Debuggerからの特定の命令に反応したりもします。

[編集] Scope protocol

Scope protocolはhostとclientがruntimeについての情報をやりとりする形式を定めた一式の規約です。例えば、runtimeからDOMドキュメント構造やa set of computed styles(?:訳不明)を取得するなどです。

Scope protocolはまだ開発段階にあり、完了と同時に公開される予定です。業者(vendor)はそれを元にデバッグclientを作成したり、IDEなどのアプリケーションに組み込むことができます。こういったclientは、Scope protocolを使ってOperaブラウザのruntimeについての情報を得ることができます。

[編集] Proxy

ProxyはブラウザとDebuggerの間のメッセージの道順を確立する役割を果たします。これはhostとclientが同一コンピューター上にない遠隔デバッグのシナリオでは特に重要です。

Operaはdebuggerの動いているOperaインスタンス内でproxyを提供しますが、proxyはパブリックサーバーで動いていてもかまいません。このため、デバッグの行われているOperaインスタンスとdebuggerの両方ともファイアーウォールの内側にいてもかまいません。

hostとclientの両方をproxyに接続する方法はOpera Dragonfly 入門 (Japanese)をご覧ください。

[編集] Debugging client

debuggerとはproxyを通してdebugging hostのscope moduleに接続するclientのことです。It receives a representation of the runtimes in that instance.(これはOperaインスタンスのruntimeについての説明を受け取ります?)。debuggerはruntimeを可視化(visualize)し、ユーザーが修正できるようにします。これはscope protocolを使ってscope moduleに要求を送り返すことで行われます。

現在のdebuggerの実装は完全にウェブ技術(HTML/XML,CSS,JavaScript)を用いて為されています。

Dragonfly-script.png
Dragonfly-dom.png
ブラウザ
Google AdSense
個人用ツール