W3C vydalo pracovní verzi XMLHttpRequest Level 2 (diskuse)

[edois]

pletu se, nebo se zase v request body nebudou dat posilat binarni data? proc se nevykaslou na xml a neudelaji obecny http request? (vzdyt to tak skoro je, az na to kodovani) :/

[MIchal Žeravík]

a to je takovy problem zapouzdrit/encodovat binarni data do json?

[edois]

samozrejme, ze je. zvysuje to narocnost (u klienta je mi to uplne jedno, ale kdyz mam na serveru 2000 lidi a busi mi tam AJAXem requesty po desitkach, tak na serveru nechci parsovat text - je jedno, jestli xml nebo json.). marshallovani/unmarshallovani dat do binarni podoby je radove o dost rychlejsi, nez parsovani/generovani textu, to je prece jasne. a o co mi jde konkretne - rad bych, aby se v javascriptu dalo naimplementovat fastrpc (fastrpc.sf.net), ale kvuli vyse zminenemu problemu to proste nejde - musi se pouzivat xmlrpc, ktere znacne zvysuje narocnost na zpracovani.

[JoHnY]

Souhlasim. Nicmene bych pomerne jednoduchej json nestrkal do stejny pytle jako XML. Rychlost je pri dobry implementaci radove jinde. Nicmene uplnej souhlas na tema binarni data.

[Daniel Kvasnička ml.]

musi se pouzivat xmlrpc, ktere znacne zvysuje narocnost na zpracovani.

Ale zas tak bych certa na zed nemaloval. Treba DWR pouziva radne komprimovany JSON a vykon je velice slusny.

[edois]

velice slusny ale neznamena, ze nemuze byt jeste rekneme 2x vyssi.. nakonec si asi vymyslim vlastni transport podobny fastrpc, ale s tim, ze bude vyuzivat jen spodni polovinu ascii nebo nejakym rozumnym zpusobem unicode pres utf8.. to by snad tim javascriptem melo projit. proste cokoliv _parsovat_ na serveru degraduje vykon. ja to potrebuju jen nejak rozumne marshallovat/unmarshallovat, aby mi server nemusel zbytecne pracovat procesorem - ted tam mam 2x dualcore xeon na 3 ghz a vidim, co ty procesory delaj. a hlavne vidim ten load. kdyz je kde setrit, tak bych setril..

[David Jaša]

Tak jim to tam napiš.

[edois]

to neni vubec spatnej napad.. netusite kam jim to napsat, aby se to dostalo k tem spravnym lidem?

[Filip Jirsák]

To máte podložené nějakým výstupem z profileru, že je zatěžuje zrovna to parsování? Já si ani nedovedu představit ten typ dat – pokud by to byl relativně velký objem, bude se s tím v JS špatně pracovat, a nějaké značky budou tvořit jen malé procento objemu dat, a parsování bude ten nejmenší problém (větší zatížení bude představovat správa síťového přenosu, kopírování v paměti atd.) Pokud by to naopak byl malý objem dat (pát bajtů), bude zase daleko větší režii tvořit zpracování HTTP protokolu. Navíc by pak velkou zátěž muselo vytvářet velké množství klientů, což bude zase způsobovat problémy úplně někde jinde, než při parsování pár bajtů. Ale jestli to máte opravdu nějak podložené, určitě by mne zajímalo, jaký typ dat to je i jaký je charakter komunikace klientů se serverem.

[edois]

nemam to podlozene vystupem z profileru, ale prostym pokusem, kdy jsem pouzil fastrpc a xmlrpc (resp. fastrpc s vypnutym binarnim modem, coz je xmlrpc) a vysledky byly zcela jasne - s fastrpc to dalo cca o 20% req/s vic, coz neni rozhodne zanedbatelne. konkretne slo o webovku, ktera pouziva jako backend server, se kterym komunikuje pomoci fastrpc/xmlrpc (a ten si to nasledne sysli v databazi), webovka je v pythonu a mnoho toho nedela, v podstate jen bere data od uzivatele, posila je do backendu, ten na zaklade toho vraci data, ktera se ve webovce hodi do tengu (http://teng.sf.net/) a vygeneruje se stranka.

pokud jsou ta data hodne strukturovana (coz casto jsou, protoze se cpou primo do tengu jako jednotlive fragmenty), tak by v xmlrpc bylo tech znacek i treba 50%, plus je debilni, ze se musi ciselne udaje v podobe textu prevadet na cisla atd.

[Filip Jirsák]

XMLHttpRequest Level 2 enhances XMLHttpRequest with new features, such as cross-site requests, progress events, and the handling of byte streams for both sending and receiving.

To pak ale musí být lahůdka s polem čísel (bajtů) v JS nějak pracovat…

[JoHnY]

on JS je vubec pekna chutovka. :) Obzlast kdyz je potreba mit podoru napric browserama. Z kombinaci jako IE5+IE6+IE7+FF jima hruza snad kazdyho soudnyho cloveka, kterej nepouziva nejakej framework na obaleni nedodelku (uz ho radci taky pouzivam, tech 15Kb nikoho na dnesnim webu nesezere a ja sedivim o polovinu pomalejc :))

[Non_E]

Programování v js pro IE6 je samo o sobě horor

[Mazarik]

Zabalte to tymto http://dean.edwards.name/packer/ a zkresate velkost tej kniznice na polovicu.