| 目次 | 前へ | 次へ |
経験からすると、アプリケーションの開発者にとっての使いやすさと、プラグインの開発者にとっての使いやすさの間に二律背反的な条件が存在する場合には、いつでもアプリケーションの開発者の方が優先されてきました。API を利用してプラグインを作成するユーザーは比較的少数であり、実際にプラグインを作成する開発者でさえ、すぐに使用するイメージ形式をサポートするためにほんの一握りのプラグインを作成するだけなのが通例であるため、複雑な事柄をアプリケーションではなくプラグインの方に押し込んでしまうというのは、道理にかなっています。
プラグイン開発の複雑さを改善するために、よく使われる機能を実行するユーティリティーメソッドや実装クラスがいくつか提供されています。しかし、あらゆる状況をカバーする実装クラスを提供するのは不可能です。しかも、提供するユーティリティークラスやユーティリティーメソッドの数が多くなり過ぎると、標準以外のプラグインを使用しない API ユーザーにまで、サイズの大きい API を使わせることになってしまいます。プラグインの開発者には、既存のプラグインのソースコードや、サンプルのソースコードを、自分たちのプラグインに組み込むように期待します。このようにして、別々に開発されたプラグインを複数使用するといくらかの冗長性が生じることがありますが、大部分のユーザーはおそらく、どんな場合でも一度に少数のプラグインしか使用しないでしょう。というわけで、理論上は共用される可能性があっても実際には共用されないコードをロードしなければならないコストの方が、多数のプラグインを使用する場合にいくらか冗長なコードをロードするコストよりも高くつく、と私たちは考えます。
メタデータ (イメージ以外のデータ) に対するジェネリックアクセスとプラグイン固有のアクセスをどちらもサポートするために、複数の形式のメタデータへのアクセスをプラグインが提供できるようにします。メタデータの形式には、プラグインに固有の形式、プラグインに依存しない、API によって定義された形式、および業界標準の形式があります。
自動および手動によるプラグインのインストールと選択 ユーザーの介入なしでイメージをロードしたい単純なアプリケーションの場合、ファイルの内容に基づいて読み込みプラグインを自動的に選択できることが重要です。ただし、不必要なのに複雑なクラスをロードしてインスタンス生成することは避けたいものです。プラグインのコード全体をロードしなくても、そのプラグインが特定のイメージを処理できるかどうかを判別できるようにしなければなりません。この目標を達成するため、プラグインのメインコードをロードしなくても簡単な照会を実行できるサービスプロバイダインタフェースのメカニズムを利用して、プラグインのインスタンスを生成するようにします。 1 つのプラグインに関係するすべてのバイトコード (.class) ファイルを、1 つの JAR ファイルにまとめることができます。そして、その JAR ファイルは、Java Runtime Environment に永続的にインストールすることも、アプリケーションの CLASSPATH メカニズムを使用して動的にロードすることも可能です。
InputStream の形式で処理しなければなりません。Image I/O API が提供するインタフェースのセットでは、File、InputStream、またはその他のソースからのデータを統一的な方法で処理することができます。しかも、後方向と前方向にシークする機能は失われていません。この API には、将来、新しい入出力インタフェースを追加する余地も残されています。たとえば、イメージのキャプチャー装置や出力装置へのダイレクトなインタフェースを、アプリケーションコードを書き直さずに使用できます。 メタデータへのアクセス イメージと一緒に格納されるメタデータは、イメージそのもののデータと同様の重要性を持つことがあります。Java Image I/O API では、完全かつ柔軟にメタデータにアクセスできます。メタデータの形式は多岐にわたり、イメージ形式に特化した情報が含まれているため、そのようなメタデータに直接アクセスする機能を汎用の API に組み入れるのは困難です。そこで、API には、メタデータを XML ドキュメントの構造にキャストするためのプラグインが必要です。そして、テキストデータだけでなく、Object による参照も可能なように拡張することができます。ここまで変換してしまえば、そのメタデータは、標準の XML DOM (Document Object Model) インタフェースを使用してアクセスしたり編集したりできます。Document の構文がプラグインごとに異なるとしても、そのオブジェクトのデータを処理 (トラバース) し、表示し、編集するのに、使用しているプラグインに特有の知識は不要です。 高度なアプリケーションのサポート 高度なアプリケーションをサポートするためには、API は、「サムネール」イメージ、1 つのファイルに格納された複数のイメージ、マルチ解像度のイメージ、タイリングされたイメージなどにアクセスする機能を提供しなければなりません。また、大きいイメージを部分的にデコードする機能や、非常に大きいイメージを見渡すことができるようにするため、デコード中にサブサンプリングを実行する機能も必要です。さらに、イメージを書き込むときには、イメージ全体を一度にメモリー内に格納しなくても、断片ごとにイメージデータを書き込めなければなりません。多くの場合、イメージの内容は動的に生成しなければなりません。たとえば、株価チャートを提供する場合のことを考えてみましょう。表示される株式ごとに、かぎられた数のチャートを前もって生成して格納しておくことも可能かもしれません。しかし、ユーザーがチャートをカスタマイズできるようにするとしたら、どうなるでしょうか。たとえば、株価を表示する時間間隔を設定したり、株価の比較対象にする指標やほかの株式を選べるようにしたりすると、前もって生成しなければならないイメージの数は指数関数的に増加します。そのようなカスタマイズを可能にするには、動的な生成というアプローチしかありません。
イメージのカスタマイズ Web のイメージは 1 つのサイズですべて間に合わせてしまうのが普通で、受信側の表示能力を考慮に入れることなく、いつも同じイメージデータを配信しています。無線端末や携帯端末が増加するにつれて、それらの端末のかぎられた帯域幅や表示能力に合わせてイメージをカスタマイズする必要が生じてきます。逆に、デスクトップコンピュータの表示解像度は大きくなる傾向にあるため、Web のイメージの多くは見え方が小さすぎるという状況も起きています。イメージを拡大/縮小できないことは、視力障害をもつユーザーにとっても問題になります。サーバー側でのイメージのカスタマイズ処理を利用すれば、すべてのユーザーに最適なイメージを提供できます。ユーザーの好みに合わせて、イメージの解像度やカラー特性を選択できるわけです。