こてさきAjax:WebSocketがデフォルトdisableとなった件 - livedoor Blog（ブログ）
拙著（「徹底解説 HTML5 APIガイドブック コミュニケーション系API編」）の補足・修正POSTです。 p.24にWebSocketをサポートしているブラウザが記載されていますが、周知の通り、以下のブラウザでデフォルトdisableになりました。 FireFox4 Opera11 ちなみに、執筆以降サポートを開始した iOS4.2.1のsafari は、現状使える状態です。 disableとなった理由は、現状実装されているバージョン（Draft76）にセキュリティ上の脆弱性が見つかったため。脆弱性がFixされた仕様がIETFで固まれば、マイナーバージョンであっても再び対応するとのこと。 http://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/ 脆弱性の詳細は、Adamさんのレポートで述べられています。 ただし
こてさきAjax:WebSocketプロトコルのframe仕様が変更されそう - livedoor Blog（ブログ）
WebSocket プロトコルのEditor's Draftに今日大きな変更がありました。 http://www.whatwg.org/specs/web-socket-protocol/ WebSocketではデータの送受信はframeと呼ばれる単位で行われます。ここで、これまでのDraft（正確には、更新されているのはEditor's draftのみですので、現状のDraftという表現の方が正確です）では、frameのフォーマットについて、以下のようにテキストとバイナリーで異なる二つのフォーマットが規定されていました。すなわち、送信するデータがテキスト（UTF-8）かそれ以外（バイナリー）かで異なるフォーマットを使う事になっていました。 text-frame (0x00-0xfe) + 送受信文字列(UTF-8の利用を前提) + 0xff binary-frame (%x80-FF)
こてさきAjax:websocketでpipelineをすると、感動的に早い!! - livedoor Blog（ブログ）
昨日、Webkit & Opera/HTML5勉強会で紹介したwebsocket&MeCabによる「坊ちゃん」への自動ルビ（ふりがな）振りデモですが、よくよく考えたら「pipelineってことは、解析リクエストの結果が返るのを待ってたらダメじゃん」ってことで、こちらのデモをwebsocket pipelineに替えてみました。 すなわち、文単位の解析依頼をとにかく送りつづけて（解析結果が返ってくるのを待たずに）、どれぐらい高速化するか見てみようというわけです。そもそも、websocketは、好き勝手に送受信できるプロトコルなので、pipeline処理にはうってつけだよね！ってことで。 あと、テキストマイニングと言えば、「やっぱり基本はわかちでしょ」ということで、websocket pipelineを使ったわかち書きのサンプルも作って見ました。 コードは、http://code.google
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
