HTTP::MobileAgentがバージョンアップ＆アーキテクチャ改修提案

HTTP::MobileAgentがデベロッパーリリースでバージョンアップしていたみたいですね。
現在5/16版の0.23_02が最新のようですが、0.23_01は3月には出ていたみたいです。
デベロッパーリリースは検索で最新にあがって来ないので、気付きませんでした...。
HTTP-MobileAgent-0.23_02

Yappoさんアタリから2月くらいに聞いた話だと、大規模なアーキテクチャの見直しがあるという感じの話が出ているという事だったのですが（私の受け取り方が間違ってる可能性もあるけど）、Changesを見る限り、マイナーアップデートとデータメンテナンスに留まっているようです。

というか、気付いた理由が、ちょうどこちらもHTTP::MobileAgentのアーキテクチャ見直しを、本家が動きそうになければやろうと思い初めて、先のcoLinux環境構築中も、理由の一つがHTTP::MobileAgentの開発環境構築だったりしますが...。
（もう一つの理由は、mod_authfoafのために、マジで作れるかは別として、Apacheモジュールの作り方を覚える環境づくりのため）
というわけで、HTTP::MobileAgent::Plugin::Extensionを作ってきた立場から、HTTP::MobileAgentの改修案を提案します。

1. 本体とキャリア毎サブクラスを分離し、別メンテナが管理
   いや、昔と違ってケータイのキャリアも機能も仕様もいろいろ増えたし、単独のメンテナが全部面倒みるのは無理ですって。
   面倒見れたとしても、つい最近まで京ぽんへの対応がみそっかすだったように、メンテナ側の温度差で各キャリアへの対応度合いが変わってしまうのも問題あり。
   ソフトバンクとか、新しいキャリアも入ってくるし、そんな時メインのメンテナが対応する気にならない限り対応できないのはよろしくない。
   そう考えると、今のアーキテクチャで、サブクラス選択の戦略が本体に含まれてしまっていては、本体を変更しないとキャリアの追加や判定条件の変更等が出来ず問題。
   サブクラス選択の戦略はサブクラス自体に持たせ、本体はサブクラスが入るはずのフォルダを__FILE__等から導出して、自動的にインストールされているサブクラスを判定し、それらの判定ルーチンを本体が順に呼び出して（或いはプラグインがuseされる際に判定戦略を本体側に登録して）サブクラスを選択する、という構造にすればどうかと思う。
   もちろん、構造として別管理できるようにするだけで、本体と一部のサブクラスのメンテナがかぶったっていいし、またいちいち本体とサブクラス両方インストールしなくてもすむように、本体はバージョンアップ毎に最新のサブクラスを同梱すべきだとは思う。
2. データの分離を徹底的に
   まあ一つ前の項ともかぶるんだけど、今ドコモのHTMLバージョン判定とか、GPS判定とか、ロジックの中に入ってしまってて変更しようと思えばコードを変えないといけないわけですが、その辺を外に出して独自にバージョンアップできるようにしないといけないなと。
   かつ、DoCoMoDisplayMapのような自動化を進めなければ。
3. プラグイン追加を標準化し、柔軟な機能追加と、本体への取り込みを容易にする
   機能の面でも、利用者毎に機能の興味・必要性への差があって、例えばFLASHへの対応度合いなんか、私は使う予定もないし使えるか否かの判定に興味はないけど、それがないと困る人もいるわけで、そう考えると、メソッド追加等のプラグインも、追加したい人が自由に追加できるような経路を作る必要がある。
   単純に、HTTP::MobileAgent::Plugin::Extensionがやってるような型グロブを使って関数を追加したり、或いは置き換えてやるようなやり方だと、本体やサブクラスの方が置き換えられたメソッドを変更したり、或いはプラグインの機能を本体に取り込もうとしても、どうしてもプラグインの機能で本体のメソッドが置き換えられてしまうので、それ以上発展させようがなｋうなってしまう。
   （これ、今まで本家の人に色々迷惑かけたと思います。最初の考えが足りなかったかもしれませんすみませんでした）
   だもんで、それを防ぐには、本体の方でメソッド書き換えや追加のためのインターフェースを用意してやって、かつ本体やサブクラスが、既に内部に取り込み済みのプラグインの名前やバージョンを管理しておいて、プラグインによるメソッド追加・書き換え要求時にその辺の条件のネゴシエーションを行ってやって、古いプラグインからのメソッド書き換えは却下する、といった構造にすればどうかと思う。
4. 完全な後方互換配慮
   HTTP::MobileAgent単独で使ってきた人にも、HTTP::MobileAgent::Plugin::Extension経由で使ってきた人にも、共通に使えるよう後方互換構造を考えたいなと思います...
5. 動作設定フラグの導入
   HTTP::MobileAgentでは一部の動作設定を環境変数を使って制御してますし、HTTP::MobileAgent::Plugin::Extensionではimport時の引数で制御してますけど、どちらもイマイチ格好悪いなと。
   （環境変数は、判らない...私が思い込んでるだけで、それが普通なのかもしれないけど）
   動作設定のフラグを用意して、それを変更するクラスメソッド・オブジェクトメソッドを整備する方が格好いいのかなあと。
   もちろん、後方互換のための手順は整備するべきですが...。
6. サブクラス判定戦略へのIPチェックON/OFFフラグ追加
   あとまあ些細な感じですが、現在のところサブクラス判定とは切り離されて、サブクラス割り当て後にメソッドでチェックする形になる、HTTP::MobileAgent::Plugin::ExtensionのゲートウェイIPアドレス妥当性チェックですが...。
   これサブクラス判定に突っ込まなかった理由はちゃんとあるわけですけども、でもIPアドレスチェックまで含めてサブクラス判定して欲しい、という要望も一部ではあるかなと。
   おかしなIPからアクセスしてきてたら、ユーザエージェントがどうであれすぐさまNonMobileサブクラスで判定するモードもあってよいかなと。

[composed and posted with ecto]