Skip to content

Yet Another IRC(仮称)のメモ+草稿

uzulla edited this page May 7, 2012 · 1 revision

本メモは https://docs.google.com/document/d/1r8W9pe7oMuFqbybc_EQR0nz040bcU6sYWyLJSnrM-YM/edit にあったものをコピーして移動したものです。 内容的に差異はありません。 改行整理とかは、そのうちやります…。

当初の目標や、アイディアなどの確認のためにこちらに移動します。

Yet Another IRC(仮称)のメモ+草稿

※この文書はHachioji.pm #15の会話をまとめた物なので、現状特別どうこうではありません。 ※Hachioji.pmを知らないのにこれみちゃった人へ、これはHachioji.pm(http://hachiojipm.org/)で、みんなでこのような物をつくったら面白いのではないかハッカソンお題です。

概要

IRCにおける以下の弱点を補完する、新しいチャットシステム ・ログが消滅してしまう(Tiarraなど不要にした) ・専用クライアントが必要(専用クライアントがなくても、ウェブで使える様にしたい) ・API的ではないのでクライアント/ライブラリの実装が複雑 ・古い(他に理由がいるのかい?)

展望としてどういう物が欲しいか

・利用しやすいAPIを用意すること ・ログが消滅せず、検索等で再利用できる事。 ・ある程度モダンにして、さわりたいと思えるように ・性能第一ではないが、実用上十分なリアルタイム性を備えていること ・基本的には認証必須にしたい

技術的な目標について

・ウェブベースだが、サーバーとクライアントの結合を疎にし、仕様を公開する ・HTTPのJSON(P) APIやWebsocketなどといったモダンかつ汎用的な仕様で実装する ・リアルタイム性を重視する ・ウェブクライアントは、Javascriptによって実装し、スマートフォン対応などを行う ・後方互換性は「割とエッジな人なら困らない程度」を目標とする(IEは…)

Hachioji.pm的な

・皆で開発できること(≒あまり性能追求・トリッキー・豪華構成にしない) ・基本的な規模は小さく、誰も拘りたくない所は割り切る(例、IE対応) ・要求仕様については、多数決でなく、一番大きい声で決める(もじもじしたらあかんで!!!!)(多数決はスピード感を殺す。後でひっくり返したってイイのだし) ・実装仕様については、自信のある人が決める。 ・テストは勉強会的側面から、「人を教育する為に」書くべきだけど、まあそれが苦痛にならないように。うごいたわーいの方が重要

当初必要な具体的な要求機能ついて

・ウェブベースで、リアルタイムなチャットを提供する ・ユーザーは認証必須で、Twitterと連携する ・タグにより、チャンネル相当の機能を実装する ・タグにより、ユーザーはストリームで受信する ・ログは全て保存され、閲覧できる ・コナミコマンドを入力したら、アバターアイコンが全部kkotaro0111のものになるall your avaters are belong to kkotaro0111機能(by uzulla&kkotaro0111)

将来的な展望について

・Notificationが欲しい(IDコールや、特定タグの発言で) ・ブラウザではないクライアントが欲しい(Prismなどで仮想化するだけでもいいか) ・Twitter以外の認証が行えるように ・ログされないタグなど、タグに意味をもたせる事を検討する ・ログは全文検索出来る

競合というか、マネするというか、参考にできるサービス

・Lingr ・Twitter ・Facebook(のチャットの所) ・https://privytalks.com/ (socket.ioらしい、RSA暗号でチャットってのも面白い)

実装仕様について

技術的な課題について

・大量に追加されていくログの保存をどうスケールさせるか >検索できる形に、完全な形での大量のテキストログを持つことは、結構チャレンジングではないか。 >Twitter的にパーティショニングで、ある程度古い物はパージしていくなど? >利用者数と性能に依存するので、このあたりは当初検討は難しそう ・タグ+日時範囲指定検索、という処理が重くてウザ委気がする、ここをどうにか解決したい。 ・日付時刻(1日分)+タグみたいなユニットで切っておいて、完全一致でファイルを引いてきて、一個あまるように取得して、その中を手動で捜査して返すとか… ・KVMがいいんじゃないかという案でたが、実際いいのか?当初は安直にMysqlの方が安全な気がしないでもない。

交換サーバーについて

・実際の所、AnyEventでCometとかつかったらコネクション数1000も無理ではないか? ・Websocketで最初から実装するべきだろうか?(IE死んだ!!IE死んだよ!!!!) ・目標をどれくらいにするのか >IRCDだと、年代もののショボイサーバーでも、5000位余裕 >たとえば、node.jsさんでWebsocketとかだと、実際どんぐらいまでいけるのさ?? >この辺り興味深い実証実験的な意味合いもあるので、まああまり深く考えない ・node.js派の意見とかも聞きたいですね。え、いないの? ・将来的には、Comet+Websocket+普通のAPIみたいなマルチスタックにしてみたいですね。 ・PocketIO+Twiggyがいいのでは(By Hide_o_55) >PocketIOにはNamespaceがない(By Hide_o_55) >ただ「タグ」として沢山のチャンネルにつなぐ今の設計だと、namespaceでわけるのはつらいので、自前でメッセージングかかないと行けない気がする…(By uzulla)

その他

・全文検索はgroongaとかどうか(リアルタイムに追加できるし、GEOサーチできる。ただ、許容できる容量は??) ・俺はArcで作る!(byGANC神(@mgiken))

機能など、前回出たネタなど

・位置情報とか面白いのでは >チャットひらいたら、ある物理イベントのチャットが「わかる|自動的にできる」とか。(uzulla) ・チャンネルという概念ではなく、タグ、という形でながすようにする。 ・タグをつけてインフラ化すれば面白いのでは >そういうのにタグなの?URLじゃないの?http://server/tag/TAGNAMEみたいにできるとか? ・タグに特殊な(ユニークな、秘匿な)ものをつかって、その上でなにかを動かす、というのはアリではないか。 ・Notificationがほしい。(メールか、Growl) ・認証はTwitter ・スマートフォン対応はやっぱりほしいね ・タグにnotagってつけるとログらないとか ・JSで公開鍵認証w ・セキュリティどうするか、SSLとか? ・議事録を簡単に保存する為、時刻範囲指定などでログを呼び出せる機能(by ichigotake) ・away機能は欲しい(by gfx)

【重要】ハッカソンでどうやるか

一番シンプルな実装については、機能的に以下の三つに分けられると思っています。 ・バックエンドAPI(AnyEvent等で実装) ・フロントエンド(HTML+JSで実装) ・ログ表示サイト(未定)

コレ三つができれば、とりあえず「うごいた!」という所にはいくのではないか。 多分「なんだこれオモチャじゃねーか!」という所ですが、まあそこまでいくかどうかの問題ですよ多分。

なので、初回はこの三つをとりあえず動く感じにしてみたいですね。 (多分、あまりこだわらなければ、ギリギリ行けるのではと思ってます)

どんどんコードは書くべきで、仕様とかまずきまらないので、大まかな仕様は事前に決めておきたいので、意見を下さい。

まったく意見が出ないのであれば(現状まるで出ていませんが)、まあたいして作りたい人はいないんだなー、諦めて一人で作ろうかなー感すごいですね!!

とりあえず

・俺はここを書きたいんだ!という心意気 ・どういう言語、ミドルウェアで作りたいか(上は別にひっくり返していいので) ・APIの仕様なら俺にまかせとけ!的な意見 みたいなものが欲しいですね。 何でもいいので、表明をしてください。さらっと意見くれればいいとおもいますし、 もしお暇があるなら、最高なのはBlog記事を書いてくれることですね。

まあ99%だれも俺にレスをくれなくて、俺が酷い設計をする事になりそうですがね!!!どうだおそろしいだろう!!!

・ざっくりとした、DBのテーブル仕様(バックエンドとログ表示サイトが利用) ・ざっくりとした、JSが叩くAPIの仕様(バックエンドと、フロントエンドが利用) がきまれば、まあ書けるかなーみたいなね。

ちなみに、サーバーはさくらのクラウドを当日用意しておきます(乞食) 事前に仕様がきまれば、必要なミドルウェアはuzullaが入れておきます。 デプロイはgitで!とか色々あるでしょうけど、そういうカッコイイやり方をみんなに教えるやる気があるすごいカッコイイ人がいなければ、なんだかんだで普通にscpかftpでULする事になるでしょう!

【重要】さて、延々書いて最後ですが、誰も特に意見をくれないのであれば、上を全部ひっくりかえして白紙にして、PHPでkentweb時代なのウェブチャットを書く会に俺がします!!!->じわじわ意見頂いており、PHPは回避できそうです(20120406追記)