ようやくというか今さらというか、d3pipesに更新Pingジョイントを追加しました。 あくまでジョイントですから、どのパイプのどの段階に挿入しても構いません。 SPAM Pingとして扱われないように、以下の２つのルールを適用してます。 - 前回から30分以内のPingは送信しない - パイプ内を通っているデータが前回と違った時だけPingを送信する 当たり前ですが、そのパイプがゲストに公開されていないと、Pingに意味がありません。メインページだけでなく、RSSも許可することを忘れないでください。 それにしても、海外の有名どころなPingサーバはほとんどextended仕様なのに、国内はextendedってだけで拒否するサーバが多いんですね。extendedの方が、サーバ側の負荷も少ない気がしますが。

前回の解析ジョイントは、サイトの新着情報などから、HTMLのヘディングを取得する、というかなり苦しい状況を想定しました。そのため、どの記事のリンクも同じになってしまいますし、公開時間が取得時間になってしまってます。 同じHTMLのみのサイトでも、もう少し構造的な情報が提供されていれば、RSSと遜色ないデータ取得が可能です。 そのサンプルとして作ったのが、Linkhtml という解析ジョイントです。d3pipes最新版には含まれています。 取得したい情報はやはり以下の４つです。それを正規表現でなんとか見つけ出します。 'heading' : 見出し 'pubtime' : yyyy-mm-dd等の表記であれば、それを自動的にUnixTimestampに変換します 'link' : 見出しを囲む<a>タグからリンクを抽出します。 'fingerprint' : ここではlinkと同じです。 L

使い方の説明はちょっとお休みして、ジョイントの作り方を解説してみます。 他のサイトから更新データを引っ張ってきたい時、業種によってはRSSが提供されていないことも多くあるでしょう。そういうサイトでは、HTMLを解析するしかありません。 逆に言えば、d3pipesであれば、HTMLを解析するジョイントクラスだけを作ればいいのです。取得もアグリゲーションも絞り込みも保存も表示も、そのまま使えます。 ※どんなサイトもRSS化する、なんてサービスもありますが、それだと細かい所に手が届きません。サイト個別に対応するなら、専用の解析ジョイントを書くのが一番です。 さっそく作ってみましょう。今回は解析ジョイントを作るので、クラス定義ファイルの置き場所は、ここになります。 XOOPS_TRUST_PATH/modules/d3pipes/joints/parse/ HTMLからヘディングをとってくるだけな

外部XML取得パターンの流れをもう少し詳しく見てみましょう。 (A) 外部XML取得パイプ XML取得 -> UTF8への変換 -> XML解析 -> 内部エンコーディングへの変換 -> 抽出 -> 保存 1) XML取得 (fetch) オプションで指定されたURIからXML文字列を取ってくるジョイントです。 対象がXMLである必要はありません。HTML等であっても、それをパースできるparseユニットと組み合わせれば良いわけです。 ジョイントの動作としては、HTTPアクセスした結果を渡すだけなので、単純なfopenでも良いのですが、allow_url_fopen=off 環境用に snoopy をデフォルトとしています。 2) UTF-8への変換 (utf8to) 最近はUTF-8でないフィードもほとんどないので、ほとんどのケースでこのジョイントは必要ないと思われます。（そのため、新規

D3 Pipesは、どのようにジョイントを組み合わせるかが全てです。 その組み合わせだけなら無限にあって、何がなんだか判らなくなってしまうでしょうが、実際には、パイプのパターンはほぼ３つしかありません。 (A) 外部XML取得パイプ XML取得 -> UTF8への変換 -> XML解析 -> 内部エンコーディングへの変換 -> 抽出 -> 保存 (B) 内部情報取得パイプ ローカル取得またはブロック取得 -> 抽出 (C) 集約パイプ 集約 -> ソート （OPMLパイプというものも将来的に予定していますが、これは(A)と(C)の組み合わせと考えることも出来ます） まずは、(A)パターンを構成してみます。 パイプ管理から「新規パイプ作成」に入ると、最初から「外部から取得:snoopy」「XML解析:keithxml」「コード変換(UTF8から):mbstring」「ローカル保存:modul

D3 Pipesとは、内外のシンジケーション情報を自在に扱うためのモジュールです。 名前からも機能からも、某!Pipesを予想させるでしょう。 ただ実は私、某!Pipesを使ったことは一度もありません。（アカウントすらない） あくまでITMediaの紹介記事を読んだだけであり、概念くらいしか知りません。 その紹介記事からインスパイアされて作っただけなので、もしかしたら、まったく違うものである可能性はあります。 さて、xhldを開発していて、何より苦労したのは、環境依存があまりにも多いことです。xhldでは、個別に対応して、その都度パッチを当てていたのですが、結果的にレンダラクラスばかりが肥大する、という結果になりました。 問題となった環境依存とは以下のようなものです。 -取得処理 --allow_url_fopen設定 (onならfopenが使えるがoffならsocketを使うしかない)