Vlákno názorů k článku
Nová verze WebSocket ve vývojovém Google Chrome od Pichi - Naposledy o vánocích jsem četl komplet specifikaci a zjistil...

Naposledy o vánocích jsem četl komplet specifikaci a zjistil jsem, že je možné posílat pouze validní UTF-8 data. Teď jsem to proletěl jen zběžně, ale nenašel jsem žádnou zmínku, že by se v tohle něco změnilo. To mi příjde jako úplná debilita. Proč tam proboha někdo zabudovává takováto omezení. Když jsou rámce v protokolu definovány délkou, tak není žádný důvod, aby byla payload cokokliv, teda klidně i to UTF-8. Tkhle, aby člověk vymýšlel nějakou formu kódování, když chce skutečně poslat cokoli. Co třeba obrázek? Pakárna na n-tou.

Protokol má do budoucna možnost přenášet binární data, ale to dnes prohlížeče neumí. Takže skutečně dnes lze přenášet pouze UTF-8 řetězce, které však nejsou definovány délky, ale ukončeny pomocí OxFF. Rámce určené délkou jsou určeny právě pro budoucí použití a pro možné přenášení binárních dat.
Nicméně přenášet třeba obrázky jako binární data nemá moc smysl – co s tím budete v Javascriptu dělat? Implementovat dekompresní algoritmy pro JPEG/GIF/PNG a pomocí canvasu vykreslovat bod po bodu. Můžete je jedině tak pomocí DOM zobrazit, což lze udělat pomocí URL schématu data: a tam musí být binární data stejně zakódovaná pomocí base64.
Nicméně k WebSockets existuje mnoho výhrad. Kromě některých principiálnách věcí je protokol popsán hixionštinou, takže je 3× delší než by misel být. Pro zajímavé čtení o nedostatcích WebSockets doporučuji např. http://blogs.webtide.com/gregw/entry/how_to_improve_websocket

Sorry za překlepy, neměl bych dělat tolik věcí najednou. Přidám alespoň ještě jedno zajímavé čtení: http://blogs.webtide.com/gregw/entry/websockets_ietf_v_whatwg

No, způsob jak je ten protokol popsán to je kapitola sama o sobě. Vlastně nechápu jak se pod něco takového firma jako Google může vůbec podepsat. To tam rovnou mohli napsat referenční implementaci v assembleru. No nic.