Když jsem si ve vedlejším blogu četl diskusi, tak mě přepadl nápad. Podstatou celé věci je ušetření kapacity přenosových linek.
Už to pravděpodobně vymyslel někdo předtím, ale podle toho co vím o běžně používaných internetových protokolech, tak to není vůbec samozřejmá věc.
Myšlenka je velmi jednoduchá. Současný trend je požívání XML značkovacích jazyků na uplně všechno. Výhod pro zpracovávání programem je velké množství. Hlavní nevýhodou v porovnání jak s binárními tak i s klasickými textovými protokoly je velikost.
Další myšlenkou je, že použití nějakého libovolného kompresního algoritmu. Moje představa o kompresních algoritmech je asi hodně zjednudušená, takže mě prosím nekamenujte když řeknu, že to funguje v podstatě tak, že se vytvoří slovník používáných slov(vzorů) a výsledek komprese je potom pozice slova ve slovníku a počet výskytů.
Mno a v čem spočívá inovativnost ve kterou tak doufam? Spočívá v tom, že je díky jazykům popisujících xml (DTD, relax ng apod.) možné velmi dobře optimalizovat vytváření slovníku pro statickou část komunikačního protokolu. Samotný slovník se nemusí pokaždé přenášet. Samotné data by se samozřejmě museli komprimovat taky. Pro určitý typ dat by bylo možné podle content-type zvolit vhodnou metodu komprese.
IMHO by bylo možné tímto způsobem data přenášet dokonce efektivněji než je tomu u binárních protokolů.
Docela by mě zajimalo jestli existuje komunikační protokol, který by komprimoval data tímto způsobem a jaké má úpěchy.
Prosadit to jako protokol mi připadá trochu nerealistické, ale stačil by nový kompresní formát (místo zipu, gzipu, raru…), který by obsahoval knihovnu všemožných značek (html,svg…). Hlásí se někdo, kdo to naprogramuje? :-)
Na druhou stranu je otázka, jestli to stojí za to (ta práce), když i "obyčejná" ZIP/GZIP komprese dokáže drasticky zmenšit velikost XML dokumentů.
http://httpd.apache.org/docs/2.0/mod/mod_deflate.html
K tomu by stačil jen filtr, kterým by se příslušný soubor prohnal ještě před kompresí. Z praktického hlediska ale nejspíš úspěch nebude valný. Ten slovník, který se má ušetřit se stejně prakticky nepřenáší. Většinou se generuje během komprese/dekomprese. Např. algoritmus LZW http://en.wikipedia.org/wiki/LZW Co se týče komprese implementované přímo v komunikačním protokolu, tuším že Volný nabízel svého času komprimovaný přenos dat přes vytáčenou linku. Při stahování textových dokumentů bylo zrychlení znatelné, ale vzhledem k rychlostem dnešních linek je zbytečné šetřit pár kilobytů na xml když se na člověka z každé druhé stránky vysype několik MB obrázků a flashů. Navíc ukládat xml komprimovaně je škoda, přece jen čistý text má své kouzlo. Možná, kdyby se toho ujal někdo jako třeba W3C, ale čert ví, jak by to nakonec skončilo. Každopádně nápad je to zajímavý. Jen tak dál, kreativita se musí rozvíjet.
A neni lepsi pouzivat jednu z dostupnych implementaci binarniho xml?
ad slovnik znacek – v XML/HTML mnohem vice mista zabira obecny text, nez pouhe znacky -> extra slovnikem pro znacky skoro nic neusetrite
ad binary-XML – dokud neni standard nema to smysl
a to ze si autor mysli ze chybi komprimovany protokol je blbost – prave typicky HTTP je komprimovane skoro vsude – servery bezne poskytuji komprimovaci sluzby a v pripade ze je browser zvlada tak automaticky komprimuji – akorat vy to nevidite.
"Navíc ukládat xml komprimovaně je škoda, přece jen čistý text má své kouzlo. Možná, kdyby se toho ujal někdo jako třeba W3C, ale čert ví, jak by to nakonec skončilo. Každopádně nápad je to zajímavý. Jen tak dál, kreativita se musí rozvíjet."
mozna ma sve kouzlo ale 100MB XML je moloch ktery se sam o sobe v textu spatne zpracovava.
a W3C se toho samozrejme ujalo – o binary XML se mluvi uz kolem 5 let (mozna i dele), uz existuji i implementace, jenom se stale nejsou schopni shodnout kterou z nich teda certifikuji
Komprimovane XML uz funguje napriklad pro SyncML klient server komunikaci
z mobilu ( kdyz to jede pres WAP tak je potreba usetrit kazdy byte)
pokud se nepletu, jabber jako takovy podporuje komprimovane xml (myslim pres zlib, pokud se nepletu)
jako priklad klient pandion
Hlavni prinos by byl pro komunikaci z mobilu.
Ale otazka je, jaka bude komprese, pokud se posle zprava s jednim slovem. Nebude potom komprimovana zprava radove vetsi nez nekomprimovana?
Jabber opravdu umi kompresi s zlib a opravdu se to na mobilu hodi. Jestli si to chcete zkusit, stahnete si treba verzi klienta Bombus s podporou zlib z http://www.jabbim.cz/support-download.html
je to sice hezkej napad, ale v 21.stoleti setrit kapacity prenosovych linek??? Zbytecny,kdyz kazdy rok kapacity narustaji….
[11] – ano narustaji – a to jenom proto ze jsou programatori lini zapojit zlib a ty linky setrit.
no ja si myslim, ze za narust nemuzou programatori, jako spise technologicky rozvoj. tfuj ho, pri predstave, ze by linky dneska byly jako linky pred 6ti lety…. zaplatpanbug za to, ze jsou lide, kteri vymysleji jak navysit rychlost linek. to ze je to provazane s byznysem je vec druha.
zlib ma podle me jine vyhody nez setreni linek. v teto variante mi to prijde zcela zcestne…
[13] neprijde – pri pouziti zlibu jsem schopen stahnout cas posilani dat az na 1/3 a mene – bezne pri komunikaci posilam pres 20MB XML treba, a tam se komprese zlibem projevi efektivne minimalne tak ze to stahnu na 7-8 MB (velkou cast XML tvori XML znacky – typicky serializovany dataset v .NETu.
takze zlib ma sve uziti. – protoze nez by klient cekal na data 5 minut, ceka jenom minutu.
no to musite tlacit tech 20MB krlesh dialup ne? ze se vam vyplati takova komprese… usetrit 12-13MB…
http://java.sun.com/developer/technicalArticles/xml/fastinfoset/
[15] pres USB na PDA pri synchronizaci – usetrit to znamena pres USB tahnout o hodne mene dat
a pri tahani z webove sluzby pri synchronizaci pres net to klient pozna jeste vice.
pri pripojeni na 512kbps linku se 20 MB taha dost dlouho na to aby to klienta prudilo
Objavili ste teplu vodu ;). Ak mate browser ktory podporuje deflate alebo gzip kompresiu, tak napr. google (a kopec dalsich serverov) s Vami komunikuje koprimovane. Vid. polozka Content-Encoding: v hlavicke.
Response Headers – http://www.google.sk/
Cache-Control: private
Content-Type: text/html
Content-Encoding: gzip
Server: GWS/2.1
Content-Length: 1531
Date: Mon, 08 Jan 2007 15:35:28 GMT
200 OK
Pekne, ale idea dotazu nebyla nezajimava.
[18] my ne ;) – pouze autor prispevku v blogu ;)
[18] rozlisuju komprimovani dat a hlavicek(znacek). v pripade xml muze byt velikost znacek vetsi nez velikost prenasenych dat. Pokud jsem to spravne pochopil, tak se v tomto pripade komprimuji pouze samotne data.
To co se mi zda zajimave je to, ze na zaklade definice formatu muzu snadno vytvorit optimalni slovnik, ktery posleze nemusim neustale prenaset – coz se muze u intenzivni textove komunikace docela vyplatit.
z toho co jsem cetl tady v reakcich se tomu imho nejvic blizi binarni xml.
[16] moc pekny link. dekuji.
jak uz tu bylo zmineno, vzhledem k tomu, ze vetsina zabraneho prostoru v html/xml na webu je prosty text, predsdilenym slovnikem toho moc neusetrime. Rekl bych ze mozna i 2% ale ty uz nikdo pocitat nebude, pocita se normalni komprimace toho dokumentu ktera dela vic jak pulku. Jde vzdycky o efektivitu reseni – predsdileny slovnik bude vec, v jejiz implementaci se daj nasekat chyby a nic uzitecneho neprinese.
Hlavni cast XML opravdu netvori znacky, ale obsahy atributu a textovych nodu. V tom nepomuze slovnik znacek, ale slovnik generovany LZW. A LZW se pro komprimaci prenasenych dat pouziva pomerne bezne..