![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
リアルタイムな伺かメモ†※注：以下は現時点ではα以前の構想段階です 現状の伺かで問題だと感じた点†開発者視点ではなく、あくまで数年ぶりに戻ってきた、いちユーザとして…
現状のボトルシステムはこんなん†「ゴーストが生きている」を体感するにはいい線いってる。(SSTP Bottle)
しかし、ボトルはあくまでゴースト作者ではなく利用者の方を向いたサービスであり、ゴースト作者にとっては使いづらい、どころか、場合によっては邪魔な存在である。また、現実問題として伺かコミュニティの中ですら、存在を忘れられつつある(笑) そして、そもそもボトルクライアントがSSPと別に起動していないと話にならない。 そこでやりたいこと†
一言でいうと†「ゴーストが自動インストールされ、透過的に起動し、デスクトップ上でリアルタイムに会話を繰り広げ、それをユーザが見て楽しむ」という状況の実現。 ボトルそっくりですが、「あくまでゴースト開発者が自分のゴーストを操るための仕組み」なので、似て非なるものです。 たとえばTwitter上では色々なゲームキャラがつぶやいています（公式・非公式問わず）し、彼らは（非実在の）キャラクター同士でリアルタイムに会話をしていたり、あるいはユーザとコミュニケーションを取ることがあります（もちろん裏に「中の人」がいる）。 これをTwitterのタイムラインなんていう狭い場所でなく、デスクトップ上で、伺かで、実現したくはありませんか? ということ。 Q: ゴーストマスターさんの負荷が高いんじゃない? 実装方法案と比較†当然の前提として、既に存在する伺かの莫大な資産を壊すようなものは作れない。また結構負荷のかかる中央サーバ的なものが当然どこかに必要。 以下の話では送信側がどうなるのか一切言及されていませんが、それこそTwitter的に、各種の投稿方法(Web、アプリ、…)がゴーストマスターには用意されるもの、と考えて下さい。 方法1：ゴーストマスタ用のSSTP Bottle姉妹版を作る†ボトルクライアントの機能縮小・受信専用版のようなプログラムが、SSPと別にWindows上で常時起動しており、中央サーバからメッセージをストリーミング受信する。Direct SSTP/Socket SSTPを使ってゴーストに喋らせる。 利点：実装が早く、SHIORIを入れ替える必要が一切無い。ゴーストマスタがユーザ登録するだけで、既存の数千体のゴーストが、アーカイブ更新の必要すらなく対応できる。 欠点：その専用クライアントが普及し、常時起動していないとお話にならない（そして今のボトルにそんな力はない）。再生可能なスクリプトはSSTPのセキュリティの範疇に制限される。この方法を使うと、「ゴーストの自動インストールと起動」という、もう一つの重要な目標が全く叶えられない。他OSとの互換性がない。 方法2：独自のSHIORIを作る†ローカルの辞書から選んで喋るのではなく、サーバからメッセージをリアルタイムに受信して喋るような独自のSHIORIを実装し、それを使ったゴーストを普及させる。 利点：実装は比較的簡単。 欠点：既存のゴーストの大半が一切対応できず、事実上「今後生まれる新たなゴーストのためだけのオモチャ」になってしまう。自動インストールは無理。 方法3：SSPが対応する†SSP自体が、ボトルのような、「インストールしているゴーストのメッセージをリアルタイムに受信する機能」を実装してしまう。（「フォローしているユーザのつぶやきを半リアルタイムに受信する」のがTwitterクライアントだから、実はイメージ的にそれに非常に近い）SSPは受信したメッセージに応じ、SSFファイルによる台本読みの要領で、必要なゴーストを起動し、受信したスクリプトを再生する。 また、「ネットワーク版ゴーストでありセキュリティ的に安全」であることを何らかの方法で認証できれば、そのゴーストは自動インストールに対応できるようにする。 利点：すでにインストールされているゴーストに関しては、（ゴーストマスタがやる気を出せば）すぐにリアルタイムな会話をするようになる。SHIORIによる準備済みの会話と、リアルタイムな掛け合いとが両立できる。 欠点：ぽなさんの負荷が凄いことになる。セキュリティ的にSHIORI込みの自動インストールは非常にまずいから、自動インストールに対応できるゴーストは今後生まれるごく限られたものになってしまう。 方法4：シェルだけ利用する、SSPとはまったく別のベースウェアを作る†「narファイルを自動ダウンロードしてシェル/バルーンだけを展開して使用する」「上記のような自動受信機能を実装する」の2つの機能に絞った、まったく別のベースウェアを（AIRかなんかで）作成する。SHIORI (DLL) という既存の仕組みから決別し、「リアルタイムなコミュニケーション」「Web上で管理されるゴースト」の世界で仕切り直す。 利点：自動ダウンロードを本気で頑張るならこれしかない。互換新ベースウェアは（作り直しだし特殊なバイナリが不要なので）他OSやモバイルに容易に進出できる。仕切り直し感が強いが、逆に過去のしがらみを捨てることで、他のサービス(Twitter等)にガチ対抗出来、あわよくば企業が採用とかまでしてくれるかもしれないような道が開けるかも。 欠点：伺か世界の再構築に等しいので、現存する大多数のゴースト作者の同意がないことには、この世界は始まらない。 方法3と4の共存†SSPもこのサービスに対応しつつも、自動インストールに対応しSHIORIを使用しない独自ベースウェアもある、という世界。 リアルタイムのメリットが認知され、オンライン上で主に活躍するゴーストが増えるなら、それでもいい。逆にオフラインでSHIORIを使うことで生まれる細やかな楽しみもあるので、それらが残る選択も良い。オンライン版のゴーストからオフライン版に興味を持ってくれる人がいるかもしれない。両方のメリットを最大限に生かしつつ、共存すればいい。 利点：自動インストールが重要な人も、既存のSHIORI資産が重要な人もハッピーになれる。 以上4方法のまとめ†
（余談）Twitterとの連携†ゴーストマスタ用のメッセージ投稿インターフェース（ブラウザ上になるのか、Tween的なデスクトップ上のクライアントになるのか、おそらく両方でしょうが）は、Twitter投稿も可能なようにしたい。（ゴーストの会話を、ベースウェア経由だけでなくTwitter上でも再現できるように同時投稿する） つまりゴースト用に\0側と\1側の2アカウントがあり、掛け合いをTwitterのタイムライン上と、ゴーストのフキダシ上の両方で再現できるようにしたい。 SSP上、独自クライアント上、Twitterに行っちゃった人、全員がゴーストのことを忘れないでいてくれる…はず。 全体像†全体像(最終形態の理想像) 中央Webインターフェース(HTML)†
中央APIインターフェース(HTTP+XML/JSON)†
Erlangで実装する ゴーストマスター向けデスクトップクライアント†
ゴーストユーザ向けデスクトップクライアント†
メモ†
|
