いわゆる Web API的なもの
ishikawa 
morimoto かっこいいなあ。 ただ、まずは2.0として正式リリースさせちゃって、さらにその先 (3.x?) を目指すブランチとしてやったほうがいいのかも?
ishikawa morimoto への返信
かっこいいなあ。 ただ、まずは2.0として正式リリースさせちゃって、さらにその先 (3.x?) を目指すブランチとしてやったほうがいいのかも?
そうねぇ(わら
2.0ベータが数年続いてるので、ちょっとあとなにをつっこむのか整理して 一旦2.0は出した方がいい気がします。
すごくわかるけど、それはkeitaircの仕事じゃないような。 やってはいけないとまでは思いませんが、すごく違和感を感じます。
こういうのは、madokaとかtiarraといった、client/server間にはさまる proxyの仕事、だと思うのでした。また、むしろそのほうがいろいろできて 都合いいような気がするのです。
とはいえ、keitaircをirc proxy + irc/http translatorの合体技ととらえて、 前者と後者をきれいに分離するように作る、ってのは（アプリケーションの 見通しを良くしようという観点でも）いいことだとは思います。
ishikawa ぶっちゃけ、これなにを意図してるかというと現状の iPhone UI が古典的なhtmlの やりとりを行う UI (って、わかりづらいな... 要は 一つのrequestに対して、単純に htmlを返して、それを表示するだけのUIでいくつものURLをもつことになるUI)に なっていて、iPhone 的には使いづらいポイントの一つなので AJAX的 UIに変更 したいんだけど(#18871)、現在のままだとちょっとやりづらいので AJAX の バックエンドになるテンプレートとそのテンプレート展開の条件を付加したいという のがもともとの意図です。
で AJAX的なバックエンドを考えるなら汎用的なデータ構造で返した方が応用範囲は 広がるだろうというのが、このチケットのもう一つのポイント。
matusita への返信
すごくわかるけど、それはkeitaircの仕事じゃないような。 やってはいけないとまでは思いませんが、すごく違和感を感じます。
うーん、どうなんでしょ。そもそものチケットの詳細にも書きましたが
これは、確かにそのとおりで その路線でいくなら keitaircでやることではないと思います。
こういうのは、madokaとかtiarraといった、client/server間にはさまる proxyの仕事、だと思うのでした。また、むしろそのほうがいろいろできて 都合いいような気がするのです。
いや、そこでは(pluginなりなんなりを作れば別だけど通常の機能としては)できないです。
madoka なり tiarra なりのいわゆるpirc的なものの機能は irc <-> irc proxy です(と とらえるのが keitairc のモデル)
で、いまここ(このチケット)でほしいものはなにか? なんでもいいからJSONPやらXMLやらで データを吐いてくれといってるのではなくて、httpのレスポンスとしてそれらが返ってほしい。
pircにはこのうち「httpリクエストを受けて返事する」機能が(通常)ない。
逆に、それがないから(かつ、madokaやtiarraのようないわゆるpircに http translator plugin みたいなものを組み込む方法とは別のアプローチとして) keitairc のような irc <-> http translator が 作られたわけです。
そういう意味で少なくとも pirc + keitairc のモデルで考えると組み込む先として適切なのはkeitaircの 位置だと思います。
とはいえ、keitaircをirc proxy + irc/http translatorの合体技ととらえて、 前者と後者をきれいに分離するように作る、ってのは（アプリケーションの 見通しを良くしようという観点でも）いいことだとは思います。
で、現状のkeitairc 2.0 はどうなっているのか? を考えると
ということをしてるわけです。すでにこういう動きになっていて、(2.をしてる大部分は4のため だったりするので、一つのプラグインが2.と4.の両方を包含してる場合が多かったりはしてるが) こういう動作を意図して構造上も(ある程度)分割されている。
で、このチケットで言ってることを実現するためにはなにをしないといけないかというと 4. を いじることになるのは明白なので、さらに 4. の部分に関して今はどうなっているのか? を見ると (デバグ用の環境変数の動きはおいといて、通常動作では)
ことが行われているわけです。つまり、http response で返されるデータ形式を切り替えることは すでに行われていて(例えば、通常の携帯電話とiPod touch/iPhoneではテンプレートが切り替えらる だけなので返されてるhtmlは全然違う)、ここに XML やら JSONP として解釈できる形式を出力する ようなものを用意すること自体には、構造上の違和感はない。
ただ、そもそもの keitairc の出発点(かつ 現在でもメインのターゲット)が 携帯であるため その携帯への出力を考えた場合、ユーザエージェントで出力を切り替える方法は非常に妥当で あるため、出力データの形式の切り替えが a. のようにユーザエージェント「だけ」に頼っている ことから、ここの仕様を拡張する必要がある。
例えば GET なり POST なりのパラメータを見て出力を(ある程度)切り替えられるようにするとかいう 修正が必要になるが、はたしてこれはアリなのかどうか? ということです。
逆に言うと、そこの修正だけの話。
ishikawa ishikawa ishikawa 結局 Webkit UI の Ajax 的なものは html ベースの処理で動くようにしてしまったので、 いまのところ強く json/jsonp/xml 的な API を用意する動機がなくなってしまった。
ということで、やりたい(とりあえず、手元には jsonp だけだけど プロトタイプ的なものは あるし)けど、これ優先度下げ目/マイルストーンからはずす ことにする。
Fork
はたしてKEITAIrcでそこまでやる? ってのもちょっと思うけど。
keitairc の本質は irc <-> http トランスレータなので、keitaircが返す情報 (チャネルリストだとかメッセージだとかいろんなもの)をとれる、いわゆる Web API 的なものがあると、UIとロジックを分離できるので、例えば keitairc をバックエンドにした flash ウィジットとか、keitaircをバックエンドにした iPhoneアプリとか作りやすくなるよね と思った。
現状、いわゆる携帯向けのUIとiPhone/iPod touchのUIをテンプレートの切り替えで 対応してるわけなので
とかやれば、とりあえずは実装できそう? (認証とかのあたりを、もう少し考え 直さないと使い勝手はちょっと悪そうかなという感覚はちょっとあるけど、それは 別途なにか考えるとして)