msanolog

[Ajax] If-Modified-Sinceヘッダを利用してWebページのキャッシュを行うXMLHttpRequestラッパー

以前書いたエントリ「[Ajax tips] XMLHttpRequest と If-Modified-Since」への一つの対応として、XMLHttpRequest にキャッシュ機能を付加するラッパーを作成してみた。

各種ブラウザ側でWebリソースの更新確認のマネージメントをきちんとしてくれるようになれば、このライブラリは不要になるので、それまでの一時対応的な位置づけ。

■ 使い方
　[prototype.jsを使用している場合]
　HTML上で、prototype.js を読み込んだあとに読み込むだけで、Ajax.Request() のGETリクエストがキャッシュつきになる。
　--------------------------------------------------------
　＜script type="text/javascript" src="/pathtoscript/prototype.js"＞＜/script＞
　＜script type="text/javascript" src="/pathtoscript/xmlhttprequestwithcache.js"＞＜/script＞
　--------------------------------------------------------

　[IEでXMLHTTPを使用している場合]
　var req = new ActiveXObject('Msxml2.XMLHTTP');
　var creq = new XMLHttpRequestWithCache(req);
　// 以降、creq を、XMLHttpRequest と同様に使用する。

　[IE以外でXMLHttpRequestを使用している場合]
　var req = new XMLHttpRequest();
　var creq = new XMLHttpRequestWithCache(req);
　// 以降、creq を、XMLHttpRequest と同様に使用する。

■サンプル
こちら

■テストしたブラウザとprototype.js
　Firefox 1.0.7
　Internet Explorer 6 SP1
　prototype 1.3.1

■ライセンス
ライセンスはGPL。
XMLHttpRequestのラッピング方法については、
最速インターフェース研究会の XMLHttpRequest for IE を参考にさせていただいた（こちらもGPL）。

■ 特徴
・XMLHttpRequest(あるいはMicrosoftのXMLHTTP) オブジェクトのラッパー。
　XMLHttpRequestと同じプロパティ/メソッドを持つ。
・一度GETしたWebコンテンツをキャッシュする。
・再度GETする際には、If-Modified-Since ヘッダを付与する。
　Webサーバ側から304 Not Modified が返る場合には、キャッシュしたデータをresponseText, responseXMLにセットする。
・キャッシュのアルゴリズムはデフォルトでLRUを採用（FIFOも使用可能）
・prototype.js の後にインクルードするだけで、prototype.jsのAjax.Request()にキャッシュ機能が付加されるようになる。

■注意点、Tipsなど
(1) HTTPステータスコードについて
prototype.js では、HTTPステータスコード304はfail扱いになってしまう。そこで、XMLHttpRequestと同じ使い勝手にするため、XMLHttpRequestWithCacheではHTTPステータスコード改変を行っている。
具体的には、実際のHTTPステータスコードが304であり、かつ、対象URLのデータがキャッシュ上に存在する場合、statusプロパティを200に、statusTextプロパティを'OK'に設定している。
ただし、HTTPレスポンスヘッダーは改変しないので、この点については注意が必要。

(2) デフォルト If-Modified-Since
初回のアクセス（キャッシュがない場合のアクセス）では、If-Modified-Sinceに「01 Jan 1970 00:00:00 GMT」がセットされる。
ただし、If-Modified-Since は XMLHttpRequestWithCache呼出し側のプログラムにて、setRequestHeader()を用いて上書きできる。

(3) キャッシュの操作
ブラウザのアドレスバーに以下のように入力することで、キャッシュを操作することが可能（もちろん、Javascriptコード内でも可能）
　・キャッシュの中身を見る（注意：キャッシュに大量のデータが入っている時にはブラウザが不安定になるかもしれません。）
　　javascript:alert(XMLHttpRequestWithCache.cache)

　・キャッシュのサイズの変更（デフォルトは100コンテンツ）
　　javascript:alert(XMLHttpRequestWithCache.resizeCache(20))

　・キャッシュアルゴリズムをFIFOにする。
　　javascript:alert(XMLHttpRequestWithCache.cacheAlgorithm('FIFO'))

[RNA] windows+IISで不具合報告

掲示板にて、「IIS6.0でRNAが動かない」とのこと。
類似環境で稼動させている方がいらっしゃったらアドバイスお願いしたいです。

【RNAバージョン】
2.0b1

【環境】
Windows2003server
IIS 6.0
ActivePerl 5.8.4.810

【不具合内容】
rna-load.cgi にアクセスすると、下記の内容が表示される。
「The specified CGI application misbehaved by not returning a complete set of HTTP headers.」
IISのログには、ステータスコード以外には、エラーらしきメッセージは無し。

[RNA] HTTPコード301 によるRSS移転に対応

（かなり）久しぶりにRNA Nightly版をupdate。話題としては少し古いが、HTTPステータス「301 Moved Permanently」への対応。

【内容】
SiteListに登録されたRSSをGETする際、レスポンスが「301 Moved Permanently」であった場合には、SiteListに登録されたURLを書き換えるようにした。

【効果】
ブログなどのサイト運営者側がRSSの移転(＝URLの変更)を行う際に、「301」で新URLにリダイレクトしていれば、RNA側が自動的にSiteListを新URLに書き換える。これにより、ユーザーが意図することなくSiteListの更新が行われ、（RSS業界ではよく問題になる）無駄なトラフィックおよびWebサーバー負荷が抑えられ、旧環境を早期に撤去（ホスティング費や運営費の問題に貢献）することができる。

背景と実装方法について以下にメモ。

]]> 【背景】
RSS移転時の措置についての議論より。
・「BloglinesのForumをタラタラと　・・・　フィードのURLを変更した時に301 Moved Permanently(301とは書いてないけど多分)でリダイレクトしてやると、自動的に新しいURLに変更される」
・「Bloglines では、301 の場合データベースの URL も変更。以降は新しい URL のみにアクセスします。302 の場合、データベースは更新せず、古いほうに継続してアクセスします」
・「301 Moved Permanentlyを出すようにすれば、一部のRSSリーダでは自動的に購読を切り替えてくれる」
・「古いRSSへのアクセスに301を返しているのだけど、自動的に移転処理をしてくれないRSSリーダーが結構ある」

【実装方法】
RNAでは、RSSの取得にLWP::UserAgentを使用している。LWP::UserAgentのrequest()では、「301」や「302」が返されると自動的にリダイレクトの処理をしてくれる。

LWP::UserAgent使用時に、「301」リダイレクト元を取得する方法としては次の２つが考えられる。
a) リクエストにはsimple_request()を使用し、1回ずつレスポンスを見て適切な処理（リダイレクト処理、SiteList更新、その他）を行う。
b) リクエストにはrequest()を使用する。得られたレスポンスから、HTTP::Responseモジュールのprevious()メソッドでレスポンスチェーンをさかのぼり、コードが「301」のレスポンスがある場合にSiteList更新を行う。

RNAでは、既存プログラムでrequest()を使用しているため、b)を採用。
初回のレスポンスが301の場合に、連続した301レスポンスの最後のLocationヘッダに記述されたURLを、真のURLとしてSiteListに登録している。

request() や previous()の動きは以下のようなプログラムを用いて簡単に検証することが出来る。

===================================
プログラムソース

[http://example/301_1.cgi]
-----------------------------------------------
#!/usr/bin/perl

print "Status: 301 Moved Permanently\n";
print "Location: http://example/301_2.cgi\n\n";
-----------------------------------------------

[http://example/301_2.cgi]
-----------------------------------------------
#!/usr/bin/perl

print "Status: 301 Moved Permanently\n";
print "Location: http://example/302_1.cgi\n\n";
-----------------------------------------------

[http://example/302_1.cgi]
-----------------------------------------------
#!/usr/bin/perl

print "Location: http://example/index.html\n\n";
-----------------------------------------------

[301test.pl]
-----------------------------------------------
#!/usr/bin/perl

use LWP::UserAgent;

my $uri = 'http://example/301_1.cgi';

my $req = HTTP::Request->new(GET => $uri);
my $ua = LWP::UserAgent->new;
$ua->parse_head(0);
my $res = $ua->request($req);

my @a = ();
while ($res) {
unshift(@a, $res);
$res = $res->previous();
}

print "Response chain:\n";
foreach my $r (@a) {
print "$uri\n";

if($r->code == 301) {
$uri = $r->header('Location');
}
else {
last;
}
}

print "\nTrue Location: $uri\n";
-----------------------------------------------

===================================
実行例

$ perl ./301test.pl
Response chain:
http://example/301_1.cgi
http://example/301_2.cgi
http://example/302_1.cgi

True Location: http://example/302_1.cgi
===================================

【余談】
RFC2616では、Locationヘッダに記述されるのは absoluteURI とある。しかし、UserAgent.pmを見ると「Some servers erroneously return a relative URL for redirects」ということもあるらしい。

[Ajax tips] XMLHttpRequest と If-Modified-Since

RSSリーダーについてさんざん言及されたように、Webコンテンツを取得するアプリケーションでは、 HTTPリクエストに If-Modified-Since ヘッダをつけるなどして対象コンテンツの更新時刻をチェックし、過剰なデータ取得を避けるのがマナーであるとされている。

同じことがAjaxについても当てはまると考える。Ajaxでは、ユーザーのアクションと非同期にHTTPリクエストを行うため、RSSリーダーと同様に人為操作を超えるトラフィックを発せさせる可能性があるからだ。

そこで、素朴な疑問。
　・ブラウザは、ユーザーが意識しないでも更新時刻チェックをやってくれる。
　・Ajaxの主なエンジンとなる Javascript は、ブラウザに組み込まれたものである。
　・Javascript の XMLHttpRequestを使用すると、プログラマが明示的にコーディングしなくても、更新時刻チェックを実行してくれるのではないか。

というわけで、簡単な実験をしてみた。概要は次のとおり。
　1) XMLHttpRequestで適当なWebページを数回GET
　2) Webサーバのログをみて、更新時刻チェックしているかチェック
なお、対象Webページは、「ブラウザで以前アクセスしたことがあるが、最終更新日時以降はアクセスしていない」状態である。
また、テスト内容は完全なものではなく、あらゆる環境および状況で同様の結果が得られることを保証するものではないのであしからず。

以下、詳細と結果。
まず、次のようなテスト用Webページを設置。
index.htmlというHTMLファイル（なんでもいい）を、XMLHttpRequestでGETするだけのJavascriptスクリプトだ。
------------------------------------------------------------------------------
＜html＞
＜head＞
＜script type="text/javascript"＞
function testfunc() {
　var xmlhttp = false;
　if (typeof XMLHttpRequest!='undefined')
　　xmlhttp = new XMLHttpRequest();
　else
　　xmlhttp = new ActiveXObject("MSXML2.XMLHTTP");

　xmlhttp.open("GET", 'index.html', false);
　xmlhttp.send(null);

　document.getElementById("r").innerHTML=xmlhttp.getAllResponseHeaders();
　document.getElementById("c").innerHTML=xmlhttp.responseText;
}
＜/script＞
＜title＞ajax If-Modified-Since test＜/title＞
＜/head＞
＜body＞
＜button onclick="testfunc()"＞click!＜/button＞
＜hr /＞
＜pre id="r"＞＜/pre＞
＜hr /＞
＜div id="c"＞＜/div＞
＜/body＞
＜/html＞
------------------------------------------------------------------------------

このWebページのボタンを数回クリックして、Webサーバーのログを見たところ、次の結果となった。
【結果１：If-Modified-Since未コーディング】
・firefox1.0.2の場合
　1回目のアクセス→ステータスコード200でGET
　2回目以降のアクセス→ステータスコード200でGET
・IE6 SP1の場合
　1回目のアクセス→ロギングされない
　2回目以降のアクセス→ロギングされない

firefoxでは、更新時刻チェックを行ってくれないようだ。
IEでは、なぜかWebサーバにアクセスしていないようだ。しかし、XMLHttpRequest.responseTextには値が入っている。ブラウザのローカルキャッシュをそのまま入れているように見受けられる。ブラウザのローカルキャッシュ（インターネット一時ファイル）をいったん削除して、再度テストを行うと、1回目だけは200でGETしてくるが、2回目以降はやはりWebサーバにアクセスしない。ここまではいいが、Webページを編集して更新時刻を変更してから再度テストしても、Webサーバにアクセスせずにローカルのキャッシュを取得し続けてしまう。テストの仕方が悪いのだろうか。この動きはAjaxアプリケーション作成時にやっかいだ。

そこで、こんどは明示的にIf-Modified-Sinceによる更新時刻処理をコーディングしてみた。Webページのスクリプト部分を次のように変更して、再度テストを実施。
（ロジックはきれいじゃないが。。。）
------------------------------------------------------------------------------
＜script type="text/javascript"＞
var last_modified = null; /*← この行を追加*/
var cached_content = ''; /*← この行を追加*/
function testfunc() {
　var xmlhttp = false;
　if (typeof XMLHttpRequest!='undefined')
　　xmlhttp = new XMLHttpRequest();
　else
　　xmlhttp = new ActiveXObject("MSXML2.XMLHTTP");

　xmlhttp.open("GET", 'index.html', false);
　if(last_modified) /*← この行を追加*/
　　xmlhttp.setRequestHeader("If-Modified-Since", last_modified); /*← この行を追加*/
　xmlhttp.send(null);

　document.getElementById("r").innerHTML=xmlhttp.getAllResponseHeaders();
　document.getElementById("c").innerHTML=xmlhttp.responseText;
　if(xmlhttp.getAllResponseHeaders().match("Last-Modified")) /*← この行を追加*/
　　last_modified = xmlhttp.getResponseHeader("Last-Modified"); /*← この行を追加*/
　if(xmlhttp.responseText.length == 0) /*← この行を追加*/
　　document.getElementById("c").innerHTML = cached_content; /*← この行を追加*/
　else /*← この行を追加*/
　　cached_content = xmlhttp.responseText; /*← この行を追加*/
}
＜/script＞
------------------------------------------------------------------------------
結果は、次のとおり。
【結果２：If-Modified-Sinceチェックを明示的にコーディング】
・firefox1.0.2の場合
　1回目のアクセス→ステータスコード200でGET
　2回目以降のアクセス→ステータスコード304でGET
・IE6 SP1の場合
　1回目のアクセス→ロギングされない
　2回目のアクセス→ステータスコード200でGET
　3回目以降のアクセス→ステータスコード304でGET

firefoxでは、それなりの動きになった。
IEでは、firefoxよりワンテンポ遅れたような動きになっている。1回目のアクセスではやはりローカルキャッシュを見ているのだろう。
結果１と結果２から総合すると、IE6SP1の動きは、「If-Modified-Sinceを付加しない場合、たとえWebページが更新されていても、何度アクセスしてもローカルキャッシュを見に行く。」ように見える。

最後に、スクリプトの「var last_modified = null;」の部分を「var last_modified = "Thu, 01 Jun 1970 00:00:00 GMT";」と変更して再度テストを試みた。
結果は、次のとおり。
【結果３：1回目からIf-Modified-Sinceをつける】
・IE6 SP1の場合
　1回目のアクセス→ステータスコード200でGET
　2回目以降のアクセス→ステータスコード304でGET

上記のとおり、firefoxと同じ動きになった。

結論としては、
「ブラウザ（Javascript）に任せず、If-Modified-Sinceの処理は自分で明示的にコーディングすべし」
となる（当たり前？）。

追記：If-Modified-Sinceを使用してキャッシュを行うXMLHttpRequestラッパーを書いてみた。

補遺
Ajaxアプリケーション作成の際、結果３の方法は十分ではない。それは、結果２においてfirefoxを「それなりの動き」と表現した理由でもある。
上記のスクリプトでは、単純なHTTPリクエストのほかに次のことを実施している。
　1) Last-Modified情報の保存（次にIf-Modified-Sinceに利用するため）
　2) Webページの内容のキャッシュ
これに加えて、本来は、
　3) 1)と2)で保存した内容の永続化（ブラウザを再起動しても前回の内容が保存されている）
が必要だ。
上記のスクリプトでは、3) ができていないので、「ブラウザをリロードしたらJavascriptが再スタートし、保存しておいたLast-Modified情報がリセットされてしまう」問題を抱えている。この問題を解決するには、次の２つが必要だ。
　i) Javascriptからブラウザのローカルキャッシュ情報（Last-Modifiedなど）にアクセスできること
　ii) XMLHttpRequestでWebコンテンツを取得した場合でも、ブラウザのローカルキャッシュに追加されること
この面については、IEの動きはある意味firefoxより優れている気がする。しかし、対象Webページが更新されていてもIf-Modified-Sinceをつけないかぎりローカルキャッシュを常に見るという動きはなんとかしてほしいところだ。

Ajaxアプリケーションが普及するためには、以上のような処理を、プログラマが意識することなくブラウザ（Javascriptインタプリタ）が調整してくれることが望ましい。何かやり方があるのだろうか。

RSSにどこまで書くか

RSS(Atom)にサマリーのみ書くか全文まで書くかという議論はずっと昔からあるような気がする。

RSS(Atom)を利用する代表的な目的はWeb情報チェックの効率化だけど、それは次のように分解できる。
　a) 「更新チェック」を効率化したい人
　　　更新があったら対象Webページを直接見に行く人。
　　　この人にとってはRSSはtitleとlinkとdateだけで事足りるのではないだろうか。
　　　glucoseなど、Webサイトを直接ブラウズできるリーダーを使うとよい。
　b) 「内容をチェックするどうかの判断」も効率化したい人
　　　この人に必要なのはtitleとサマリー（＜description＞や＜summary＞）だ。
　　　サマリーをざっとみてさらに詳しく見たければ直接Webページをブラウズする。
　　　重要な点は、まともなサマリーがちゃんと書かれているかということ。
　　　先頭n文字で切っているだけの＜description＞はサマリーとはいえないと思う（文章のうまい人は先頭n文字が要約になるような書き方をするのかもしれないけど）。　　　
　c) 「内容チェック」までも効率化したい人
　　　この人にとってはRSSに全文が含まれていることが望ましい。
　　　サマリーでも代替になるだろうが、内容を取得元Webサイトに確認しにいく必要の無いほどの、秀逸なサマリーが常に配信されている必要がある。

RSSにどこまで書くかという話は、RSS利用者側が何を必要としているかという問題になる。同じ人でも、スポーツニュースはサマリーでよいが、政治ニュースは詳細を知りたいかもしれない。

たとえば、次のように詳細度の異なるRSS(Atom)フィードを3種類おいておく方法が考えられる。
　1) title, link, date のみのフィード
　2) 1) に加えて記事のサマリーが記載されているフィード
　3) 2) に加えて記事の全文が記載されているフィード
RSS利用者側が自分のライフスタイルに合わせて利用するフィードを選べば、帯域消費緩和にもつながるかもしれないし、RSS提供側も悩まなくてすむ。
本当に3つファイルを作成したら今度はストレージの消費が問題になるというなら、実体のファイルは1つにしてWebサーバーのプラグインなどで複数バリエーションのフィード配信を実現すればよい。リーダーから見えるRSSが同じであれば使い勝手は変わらない。ただし、Webサーバーの負荷は逆に高まってしまうことになる。アプローチとしては、VFZ（今のPixelLive）に似ていると思う。VFZは、色深度という観点で画像データを分解して再結合した形式で、利用者のニーズに応じて特定の色深度レベルのデータのみ配信することができる。また、そのようなデータの再構成により、結果的に(おそらくbitmapと比較して)データサイズが小さくなっている。RSSなどのテキスト系メタデータの分野でもそのようなことができないだろうか。サイズが減るという現象は(gzipなどの圧縮の適用を除いて)考えにくいが、自然言語文章から意味の要約を抽出する優秀なアルゴリズムがあれば要約のためにストレージを消費する必要は無くなるかもしれない。

RNA nightly build 050405

以下の条件で文字化けが発生するケースについて修正。

条件 : perl 5.8.x 使用時
対象 : UTF-8以外の文字コードを使用しているRSS
修正方法：
　nightly buildでは修正済み。
　ver2.0b1の場合の修正方法は次のとおり。
　(1) lib/RNA.pm（522行目あたり）を次のように編集する。
　　　[修正前]
　　　$new_cache_data->{$uri} = {content=>\$str,

　　　[修正後（1行増えています）]
　　　my $cachestr = $str;
　　　$new_cache_data->{$uri} = {content=>\$cachestr,

　(2) cache/site/ ディレクトリの中のファイルをすべて消す。

気づいたこと

「情報考学」のトップページにおいて、記事のpost date が全て 23:59 であることに気づく。偶然？

RNA: 想定未来の集約抑止

RNA nightly版をupdate。
RNAサポート掲示板に報告された、「未来日投稿を載せない仕様になったrnanightly版でも、サイトリストの更新日では未来日が載ってしまう」という現象に対する機能追加。
lib/RNA/Config.pm にて、「my $allow_future_entries = 0;」とすると、次の２つのことを行うようにした。
1) 未来日付を持つを削除する。（従来からある機能）
2) channel/dc:date が未来日付を持っている場合、1) で削除されずに残ったのうち、最新のitem/dc:date で channel/dc:date を上書きする。

「my $allow_future_entries = 0;」の設定はデフォルトにした方がよいかもしれない。

XML-RPCのJavascript実装

最近ajaxというアーキテクチャがはやっている。
それはそれはやたらはやっている。

ajaxの肝の一つに、クライアント（ブラウザ）とサーバーの非同期通信というのがある。そうなると、通信プロトコルをどうするか、といった話が盛り上がってもよさそうだ。（独自路線をつっぱしる人はそれはそれでよいと思う。なんせ、XMLHttpRequestオブジェクトは、ブラウザによっては自分自身のサーバーとしか通信できないらしいから）。

で、ここ数年のblogの盛り上がりから、やっぱり、まず検討すべきは XML-RPC だと考えている。
そこで、誰かライブラリ（XML-RPCのjavascript実装）を作っていないか探してみた。google://javascript+xml-rpc
どうも、ぱっとしたのがない。？？
ふと思い立って worldwideでgoogle://javascript+xml-rpc
してみたら、、、いろいろでてきた。日本はだいぶおくれているのか？私の探し方が悪いのか？

一通り機能がそろっていて使えそうなのは、次の２つ。
1) vcXMLRPC
　　ライセンス：GPL
　　Copyright が2000-2002と古い。
　　一つのファイルにまとめられていてコンパクト。
　　IEとfirefoxは大丈夫そう。safariはどうだろう？
　　　　
2) JavaScript O Lait
　ライセンス：LGPL
　　Copyrightは 2003-200４で、結構あたらしい
　　８つのライブラリファイルに分かれている。（XML-RPCを使いたければ、xmlrpc.js, xml.js, urllib.js が必要。）
　　中身をさらっと見た感じでは、どのブラウザでも使えるようにつくってある気はする。（実際につかってないので、なんともいえない。）

vcXMLRPC をちょっと加工して使ってみようかな。
JavaScript O Lait は品質が高そうなんだけど、ちょっと大掛かりなので。

ところで、JSONってなんなんだろう。。。

RNA nightly への最近のupdate

RNA nightly

1) カテゴリごとのページを作成できるようにした。
2) del.icio.us にPost、del.icio.us からclipにimportできるようにした。

とくに、1) は、イントラblogでの利用に重要な意味を持つと思われる。
blogにおけるカテゴリ運用の形態として、
a) blogは1つ。カテゴリは複数
b) カテゴリごとにblogを設置
があると考えられる。2つを比べるとa) の方が面倒さが少なく柔軟といえる（ b) だとカテゴリが増えるたびにいろいろ作業が発生する）。
a) の場合、一つのサイトに複数のトピックが並進することになる。あるトピックに着目すると、比較的近いキョリ（物理的な距離だけではない。同じチームに属するとか）にいる複数の人が同じトピック（カテゴリ）について語っているという状況が発生しうる。その場合、RNAは人に対して横断的に１つのカテゴリを追うための「ビュー」を提供することができる。
個人的には結構おもしろいと思う。

あとやりたいことは、
・未読既読管理とRSS配布
・autoClipモード

どちらも、チェックボックスなどで on/offを切り替えられるようにしたい。 onのときは、URLをクリックしただけでclipされるとか。ブラウザ側で（つまり、javascriptで）切り替えられるのが理想。

RNA nightly 説明書

RNA説明書（nightly版）を作成した。
その名のとおり、RNAnightly版用の説明書。
特に、要望の多かったテンプレートタグについての説明を追加。

javascript の XMLHttpRequest

http://www.scss.com.au/family/andrew/webdesign/xmlhttprequest/

javascript で、サーバーと通信できるプログラム。
しかも、Cross-Browser。

これをRNAのテンプレートに入れていろいろやってみたいが、ライセンスが「帰属、非営利、同一条件許諾」なので、デフォルトテンプレートに入れるにはちょっと制限がきつい気がする。

テスト

msano復活の布石

test

test 書き込み

導入事例 - PIXUS 80i + Planex PLANEX GW-BH03U + 自作PC（WinXP SP1）

先週の日曜日に手に入れた PIXUS 80i の Bluetooth 印刷用セットアップをようやく終えた。

パンフレットを見ると、Bluetooth 印刷は限られた機種でしか使えないようなことが書かれてあった。
Bluetooth は使ったことが無くてよくわからないが、どうしても使いたいし使えるだろうと思い、買ってみることに。でも根が軟弱なので、ビックカメラ（秋葉とかでないあたりも軟弱か）の店員さんに聞き込み。前提条件や考慮事項を聞いていると、３人目の方から「（Canonも私も保障しないけど、）普通のBluetoothアダプタとWindows XP の組み合わせならいけるはず。」というありがたいお答えをいただく。安心は得たので、 PIXUS 80i と Bluetooth ユニットと、PLANEX GW-BH03U を購入。

予想通りうまくいった。

せっかくなので、導入事例として setup log を記しておく。

]]> ■ PCについて

自作PC
Pentium4 1.6GHz
SDRAM 512MB
Windows XP SP1

CD-ROMドライブを「G:」とする

■ 使用した機器

プリンタ：PIXUS 80i
プリンタ側 Bluetoothユニット：BU-10
PC側 Bluetoothデバイス：PLANEX GW-BH03U

■ PIXUS 80i の導入

・マニュアルにしたがって、インクなどを装着
・付属CD-ROMのマニュアル
（G:\MANUAL\manual\Japanese\Windows\Bluetooth\1.0\top.htm）
にしたがって、Bluetooth ユニットを装着
・電源を入れる
・PCと PIXUS 80i を USBケーブル（BU-10に付属）で接続する
・インストーラ（G:\MSETUP.EXE）を起動し、「電子マニュアル」「プリンタドライバ」「PIXUS 80i Setup Utility」をインストール（電子マニュアルは必須ではない）
・テストページを印刷できることを確認する。

■ PLANEX GW-BH03Uの導入

・GW-BH03U をPCのUSBポートに装着
・GW-BH03Uのマニュアル通りに、ユーティリティとドライバを導入

■ PIXUS 80i Bluetooth の設定

・USBケーブルを抜く
・タスクトレイにあるBluetoothマークを右クリックして、
「My Bluetooth Place を展開」を選択
・ウィンドウの左側にある、「範囲内のデバイスの検索」をクリック
・しばらくすると、「Canon 80i．．．」といった名前のアイコンが出現するので、
ダブルクリック。
プリンタをインストールするかどうか聞かれるので、「O.K.」を選択
・「Canon PIXUS 80i (Copy 2)」といったプリンタが追加されるので、「Canon PIXUS 80i (Bluetooth)」などのわかりやすい名前に変えておく
・ここまでで、Bluetooth から印刷できるようになっているはず。

■ アクセス制御（GW-BH03U）

・タスクトレイの「Bluetooth」アイコンを右クリック → 「詳細設定」→
「アクセス性」タブで、「ほかのBluetoothデバイスから・・・」のチェックをはずす

■ アクセス制御（PIXUS 80i）

・USBケーブルを装着し、
「スタート」メニューから「PIXUS 80i Setup Utility」を起動
・Bluetooth設定を「変更」
・「アクセスを拒否する」にチェック
（これにより検索はできなくなるが、印刷はできる）