msanolog: semblog アーカイブ

October 01, 2005

[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のログには、ステータスコード以外には、エラーらしきメッセージは無し。

投稿者 msano : 03:45 PM | コメント (0) | トラックバック

September 19, 2005

[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」ということもあるらしい。

投稿者 msano : 12:01 AM | コメント (3) | トラックバック

April 05, 2005

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などの圧縮の適用を除いて)考えにくいが、自然言語文章から意味の要約を抽出する優秀なアルゴリズムがあれば要約のためにストレージを消費する必要は無くなるかもしれない。

投稿者 msano : 11:47 PM | コメント (0) | トラックバック

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/ ディレクトリの中のファイルをすべて消す。

投稿者 msano : 11:31 PM | コメント (0) | トラックバック

March 25, 2005

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;」の設定はデフォルトにした方がよいかもしれない。

投稿者 msano : 02:20 AM | コメント (0) | トラックバック

February 23, 2005

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で）切り替えられるのが理想。

投稿者 msano : 10:51 PM | コメント (0) | トラックバック

RNA nightly 説明書

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

投稿者 msano : 10:48 PM | コメント (0) | トラックバック

November 05, 2004

test

test 書き込み

投稿者 msano : 01:13 AM | コメント (0) | トラックバック

August 11, 2003

OPML のインポート

OPML のパースには，XML::SAX::PurePerl を使うことにした．
理由は，ずばり，PurePerl だから．

RSS のパースは自前のコードでやっていたが，今後のためと勉強のために，CPANモジュールをつかうことにした．でも，expat に依存しているやつがだめとなると，結構どれがいいのかよくわからん．とか考えながら探していたら，XML::SAX::PurePerl が見つかった．

名前のとおり，Pure Perl なので，基本条件は満たしている．
作者が，
「XML::SAX::PurePerl is slow. Very slow. I suggest you use something else in fact.」
とか言っているのはちょっと気になるし，RSS 読み込ませたら途中で止まって OS の動きが鈍くなったりしたのだが，OPML のパースはきちんとやってくれている模様．

投稿者 msano : 12:58 AM | コメント (1) | トラックバック

July 25, 2003

OPML

OPML について勉強．
「OPML an XML-based format that allows exchange of outline-structured information between applications running on different operating systems and environments.」
世界を RDF の網で覆おうとする RNA にとって，これは対応すべきフォーマットなのか．

OPMLの仕様を見てみる．
個々の要素を示す，の中身とか属性とかについては，詳しく言及されていない．みんな，独自定義をしているのか．
信用できそうなのは，bulknews のやつかな．
RNA の site.rdf を表現するなら，このページに近い書式になるのだろう．カテゴリの表現があるから．

投稿者 msano : 11:19 PM | コメント (3) | トラックバック