大人な事情により Apple の審査通りませんでした（ツイキャス・ビュワー） : 管理人@Yoski
さて、先日 Tokyo2.0 で発表した新アプリ、「TwitCasting Viewer（ツイットキャスティング・ビュワー）なのですが、本日 Apple より正式に「却下！リジェクト！」の連絡が来ました。 リジェクトの理由がシステムの根底に関わる問題のため、ビュワーの提供はまた少し先になります。申し訳ありません。 Apple 側から公開されている（NDAに抵触しない）範囲内でリジェクトの理由を書いておきますので、なにかの参考にしていただければ、と。 さて、ツイットキャスティング・ビューワーでは - PUSH によるライブ開始の通知 - 独自プロトコルによる 64kbps ～ 1Mbps 帯域での柔軟な環境での視聴 を可能にしています。 問題は、この「独自プロトコル」で、Apple 側は今年2月に - 10分を超える音声・動画、もしくは (NDA)分間で (NDA)バイトを超える音声・動画を
Big Sky :: javascriptで動くtwitter streamクライアントを作るならばmultipart/mixedを使うべき
twitter stream APIとは、twitterのステータス更新に対してキーワードでtrackしたり、あるグループ内に属するステータス更新をフィルタしたり出来るAPIなのだけど、実際にはchunkedなストリームが流れて来ているのであって、これを使ったWebアプリを作る際にはlong pollを使うのが良い。ただしクライアントサイドでjavascriptを処理する際に サーバサイドでステータス更新をFIFOに溜め込む クライアントからリクエストをブロック(long poll)しFIFOからステータスを送出する クライアントサイドでlong pollを行い画面を更新する 再度サーバへリクエストを投げる を繰り返すのであれば、せっかくストリームなのにアプリサーバとの接続を切ってしまう事になる。出来ればクライアントからWebアプリもストリーミングとしたい。しかしながらサーバからのステータ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
