Narazil jsem na zajímavost – firma AOL, což je provozovatel u nás tak populární sítě ICQ, se otevírá klientům třetích stran. Končí tak dohady o tom, zda je nějaký klient nabízející chatování po ICQ legální či ne. Doba se mění a pokud se nepřizpůsobíte, může se stát, že upadnete v zapomnění.
Pokud se podíváte na stránku AOL Developer Network, najdete tam docela dost informací o tom, jak naprogramovat svého vlastního klienta. K dispozici je podrobná dokumentace protokolu OSCAR, můžete mít i AIM SDK. Prostě takový obyčejný open source projekt.
Má to drobnou vadu na kráse, ale zase to není až tak nepoužitelné. Jako jednu z prvních jsem začal číst stránku Terms and Conditions, tedy pravidla, kterými se jako vývojář klientského programu musím řídit. Nečetl jsem podrobně licenci, spíše jsem se zastavil u jiných podmínek (i když věřím, že licence má také nějaké háčky). Mně spíše zaujala nutnost implementovat jisté funkce do svého klienta. Abyste mohli program vytvořit, musíte si vybrat 2 z pěti možností :
1) Reklama
2) Buddy Info
3) Expressions a Buddy icons
4) Startovací stránka
5) AIM nástrojová lišta
A teď podrobněji :
Reklama
Implementace okna zobrazujícího reklamu se skriptem od AOL v rozměrech :
Odměnou vám může být to, že se můžete podílet na ziscích z reklamy. Dosti podstatná podmínka je, že pokud váš program bude používat ve špice více než 100 000 lidí, musíte reklamu implementovat automaticky jako jednu ze dvou vámi vybraných funkcí.
Buddy Info
Tato funkce je prý velmi oblíbena a slouží k zobrazování informací o uživateli jako je stav jeho připojení nebo AIM profil a tyto informace musí být zobrazitelné na jedno kliknutí.
Expressions a Buddy list
Tohle je jakási obdoba uživatelských stránek, je zde možno stahovat si nové obrázky, ikony atd. Opět je podmínkou přístup na jeden klik (odkaz nebo tlačítko). Buddy list by měl být seznam vlastních kontaktů.
Startovací stránka
Po spuštění vaší aplikace se musí objevit příslušná startovací stránka. Je však možné do nastavení přidat funkci, která zobrazení Startovací stránky po startu klienta zakáže, musíte však přidat jednoduchou možnost stránku zase zapnout.
AIM Nástrojová lišta
jedná se o samostatnou aplikaci, která implementuje lištu s odkazy na různé stránky, služby atd. Stačí implementovat možnost instalace lišty do vašeho instalátoru aplikace. Problém je, že je to EXE soubor, tudíž WIN záležitost, v Linuxu nepoužitelné.
A teď si to vše shrňme :
A jak se podle mne zachovají vývojáři? Jednoduše – pravděpodobně začnou vyvíjet programy, které budou schopny využívat ICQ síť a pravděpodobně implementují druhou, třetí nebo čtvrtou možnost. Možnost číslo 1 až následně. To zní celkem zajímavě.
A jak se zachová AOL? Podle mne začne hon na klienty používající ICQ bez implementace OpenAIM. V podstatě je to docela chytré řešení, neboť podmínky ICQ licence byly v některých chvílích obecné a nikdo si nic nedělal z jejich nedodržování, protože se objevovaly názory, že by to pro ICQ znamenalo smrt, pokud by AOL začala dbát na dodržování podmínek. Teď získala AOL do ruky mocný nástroj, který je jasně definován a je pravděpodobné, že jej programy typu Pidgin nebo QIP implementují.
Více méně AOL připravila jakýsi postup pro to, jak schvalovat klienty, umožnit nezávislým vývojářům svobodně vyvíjet a zároveň mít vše pod kontrolou. Myslím si, že později budou následovat kroky, které prostě znemožní fungování „necertifikovaných“ klientů. Takže uvidíme, kdo bude v Linuxu první…
Každopádně to znamená, že ICQ podmínky budou nyní jasněji definovány. V konečném důsledku to koncové uživatele asi moc nezajímá, vývojáři to však budo mít jiné. Budou se moci dostat k protokolu a napsat klienta s podporou ze strany AOL. Otázkou je, zda bude poptávka, podmínky se mohou jevit docela striktně.
Stále ještě zůstává (pro mne) tajemstvím, co je vše v licenci popsáno, podrobněji jsem to ještě nezkoumal.
Nerekl bych za AOL nechce psat nove klienty.
To ze se budou pouzivat pouze jejich klienti je jejich nejvetsi sen, nastesti nesplnitelny.
Ale jdou na to rozumne, kdyz nemuzou cizi klienty zakazat, tak je lepsi s nima spolupracovat. Odmenovat ty co prispeji k zisku a naopak blokovat ty, kteri nebudou dodrzovat vseobecna pravidla.
IMHO je otázkou, zda by program který by využíval ty jejich specifikace mohl být šířen pod GNU GPL licencí. Dejme tomu že napíšu takový prgram, dám do něj něco co oni chtějí, a vydám ho pod GNU GPL, druhý den udělá někdo fork a odstraní jenom ty věci co do toho chce AOL, GPL neporuší, ale vlatně bude porušena licence specifikací. Proto si myslím že program toto využívající nemůže být pod GPL.
Mně by hlavně zajímalo, podle jakého zákonu ty podmínky chtějí vynucovat.
Podle autorského zákonu to nejde, protože ten se na rozhraní nevztahuje. Formát packetu není autorským dílem.
Nebo podle patentů? I když o těch se tam nezmiňují, a navíc v Evropě nejsou.
Když někdo na web napíše "pokud vyvinete aplikaci, která má funkcionalitu A, musíte do ní přidat funkcionalitu B, C, D nebo E", tak to nemá žádný právní význam, nikdo se takovým tvrzením řídit nemusí.
Nebo někde na světě existují zákony, které by omezovaly implementaci protokolů? Nikdy jsem o tom neslyšel.
13: Nechci se hádat, ale jak jsem teď velmi letmo nakoukl na specifikaci toho protokolu, tak tam výskyt řetězce ICQ zaznamenávám celkem často.
V tomto kontextu mne taky velmi těší, že tam často zaznamenávám výskyt řetězce UTF8. Snad konečně přestane být bordel v kódování diakritiky, který dělají právě alternativní klienti.
Nemáte pravdu.
Jde o licenci, tedy smlouvu kterou uzavíráte tím když si čtete ten jejich inplementační návod.
Smlouva je smlouva všude nasvětě.
Dále také uzavíráte jistou smlouvu tím že používáte síť icq.
Tuto smlouvu porušíte jestliže použijete neautorizovaný klient. To je ovšem problém jednotlivých uživatelů. Nikdo vám nezakazuje takoví klijent vyrobit ale nesmíte ho používat.
Jinak např: když dete v praze do metra tak tím uzavíráte smlouvu s dopravním podnikem hlavního města Prahy.
Jesi to nedává smysl tak sory.... byla krutá noc.
Já mám naopak zkušenost že sami klienti windows používají někteří win-1250 a někteří utf-8. Musím si přepínat jeho podle toho z jakého stroje se ten člověk zrovna hlásí. A protože minimálně ve starších verzích protokolu - staršívh klientech se typ kódování nepřenášel vůbec je v tom teď takový bordel. Celkem to nechápu, zrovna izrael pokud vím v ASCII nepíše.
[18] Nejhorším klientem je QIP co se týká kódování - na pořádnou implementaci ICQ protokolu kašle a pošle to tak jak se mu to líbí aniž by dal šanci druhé straně poznat co vlastně poslal.
Jinak ale miranda, kterou používám už léta zásadně posílá vše v unicode snad co jí znám.
Ale na Linuxu asi budou mizerní klienti, protože lidé od Linuxu mi stále píšou bez diakritiky s tím, že mají problémy a zároveň nemají problémy moje české texty číst.
Ale ať už se ICQ říká cokoli, jeho protokol je vymakaný - a hlavně binární! Tedy úsporný, rychlý, snadno zpracovatelný, tedy efektivní. Na rozdíl od mamutích kanónů na vrabce co posílají XML (nechci jmenovat), což je na houby.
A co SSL? Umí ICQ už SSL?
Popravdě otevření protokolu byl ten největší problém, ale potěšilo by mě, kdyby se časem ICQ posouvalo směrem k Jabberu, tj.:
- Šifrování proti serveru
- Šifrování proti ostatním klientům
- Vlastní servery (tj. nekdo@nekde)
- Transporty
- Standartizace kódování textu (standart pro kódování (UTF-8/16?) formátování, Smajlíky - kolik z vás už tolikrát dostalo zprávu obsahující text "*JOKINGLY*" ?)
- XML protokol?
Potom by protokol byl příjemný jak pro vývojáře, tak pro uživatele, tak pro AOL (ulevil by jejich serverům).
Samozřejmě by mi nevadilo, kdyby takovýmto postupem zlikvidoval Jabber, nebo se s ním mergnul (za předpokladu, že AOL ustoupí od požadavků na reklamy, atd...)
Nová rozšírená iniciatíva Open AIM pre prístup do siete AIM nezahŕňa sieť ICQ prevádzkovanú AOL na rovnakom protokole.
Pre server DSL.sk to uviedol Greg Cypes z AOL.
Oficiálne tak AOL stále nepodporuje alternatívnych klientov pripájajúcich sa do siete ICQ.
Zároveň tým vzniká paradoxná situácia, keď klient podporujúci zároveň AIM a ICQ fungujúce na rovnakom protokole (napríklad Pidgin, Miranda, Trillian, atď) sa oficiálne môže rovnakým protokolom pripájať s AIM účtom ale nie s ICQ účtom.
[16]: a podle jakého zákona je čtení textu považováno za uzavření smlouvy?
Pozor tenhle příspěvek je (c) BLEK. Pokud ho čtete, tak souhlasíte s licenční smlouvou tohoto příspěvku, podle které jste povinen, kdykoli se na příspěvek podíváte, si třikrát uprdnout. Dále, pokud vyvinete software schopný tento příspěvek zobrazit, musíte do něj implementovat reklamu podle vůle autora příspěvku.
"Dále také uzavíráte jistou smlouvu tím že používáte síť icq."
Opět --- podle jakého zákona uzavíráte smlouvu tím, že používáte internetovou službu? Jediné, co ti za porušení takových podmínek mohou udělat, je smazat ten ICQ účet.
"Jinak např: když dete v praze do metra tak tím uzavíráte smlouvu s dopravním podnikem hlavního města Prahy."
To, že když vlezeš do metra bez jízdenky, tak musíš platit pokutu, má oporu v nějakém zákoně. Otázka je: kde je takový zákon pro internetové služby?
[20] A pusť si někdy mirandu - najdi si v Option -> Network -> ICQ nastavení a vylaď si to jak chceš. Pokud Ti jde o minimalizaci přenesených bajtů, můžeš se dostat v obrovském rozmezí, o kterém se Ti ani nesní
Binární protokol ICQ je určitě velmi výrazně efektivnější na poměr užitečné_funkce/přenesený_počet_bajtů, než XML.
XML je hlavně móda - je prostě in používat XML na vše a jistě (ironie)se brzy dočkáme nahrazení TCP a UDP protokolů něčím na bázi XML :-)(konec ironie). Nevidím zde ale nic, co by XML přinášelo za plusy, vidím jenom mínusy.
[23]: Ten protokol neznám, každopádně se mi zdá, že IRC pošle dohromady míň blbostí v paketu se zprávou - tj.:
- tohle je zpráva
- adresát je XY
- text je XZ
Mirandu nemám - sry, ale sem LINUXák. (sme na rootu ne? ;)
Ano XML me taky stve, pac se to blbe parsuje u nizsich jazyku (jako C), nadruhou stranu sou mozna naky pekny libky. Pouzivat to v protokolu ma svoje + v podobe snadneho rozsirovani protokolu se zachovanim kompatibility a - v podobe prenesenych dat. Ale ono treba HTTP se da taky rozsirovat a zustane kompatibilni bez nutnosti hromady spicatych zavorek, etc...
[24] Jenže IRC je trošku jinde, než ICQ. ICQ se na tu samou komunikaci dá velmi snadno osekat se stejnou výslednou efektivitou, ale proč?
Ohledně toho Linuxáka, lidi taky pouštějí pod Linuxem třeba Photoshop, takže ...
Mě jen zajímá, jak třeba v jabberu přes XML budou posílat streamované video, ale raději to opravdu nechci vědět, dneska už jsem zvracel.
A XML nepřináší snadné rozšiřování protokolu, toje lež jako věž. Protože to samé, daleko snadněji a bez parsování uděláte s binárním protokolem taky. Koneckonců k čemu Vám je, že máte na XML libku, když ta libka neudělá nic jiného, než to dostane do tvaru, ve kterém extrahuje data? Tedy do stavu, ve kterém je binární protokol už zcela přirozeně a tento krok není vůbec potřeba.
Nevidím jedinou, absolutně žádnou výhodu XML v protokolu a to se strašně moc snažím, mám za sebou tvrdých 20 let programátorských, analytických a jiných zkušeností, ale fakt nevidím. Jenom nevýhody, nevýhody a místa, kde to dře.
XML je moderni a je to moda, na tom urcite neco (mozna ne malo) bude. Ale zase jsou situace, kdy je to XML fajn. Treba tam, kde ukladam data, na kterych me celkem zalezi. Je pak rozdil dostat z dat aspon neco treba lidskym okem, nebo vubec nic, pokud je to binarni format.
Nemam nic proti jednomu ani druhemu. Zacinal sem tezce binarne (na Atari 130XE), ted sem si zamilovat jednoduchost serializace do XML (CLI). Jiste je i binarni serializace, ale ta se neda uzit treba jako konfiguracni soubor :-)
Pokud je na xml dobry parser, pak se postara o spoustu veci a mi jako programatorovi z toho vypadnou data, ktera vetsinou muzu rovnou pouzit (ve zkratce receno). Samozrejme kazda obecnost (obecnost parseru a formatu) prinasi rezii navic. Pokud si ji muzu dovolit, pak mam jako programator min prace a treba i snadnejsi debugovani.
Co se tyce ICQ, tak nemam rad jejich klienty, nemam rad mirandu (fakt sem tomu neprisel na chut), nemam rad nejaky ten trilian, a na linuxu sem si jeste davno nejake snad Licq taky moc nezamiloval. A to sem chtel fakt jen posilat zpravy.
Jabber a jeho klient Psi mi vyhovuje, dnes ho uzivam primarne na windows, ale mel sem ho i na linuxu a ve skole na MacOSu taky jel bez problemu. Jabber celkem jede, prispel jsem na provoz serveru jabbim.cz nejakymi 300 CZK, ICQ transport za 95% taky jede, mam rad SMS transport, ten taky jede dobre, mam rad i slovniky a obcas uziju i TV program. Ted jsem poprve vyzkousel 1.5GB JabberDisk, kam sem vystavil data a poslal odkazy ostatnim lidem, aby si soubor stahli. Nevim o tom, ze by tohle vsechno ICQ pro me lidsky umelo. Co icq klient, to original, kazdy to przni po svem. treba qip ve vychozim stavu posila neco jako UTF, ale misto ceskych znaku je azbuka (tak kde je to UTF?!) a podobne. jedna prasecina vedle druhe. nebudu trvrdi, ze Jabber nas vsechny zachrani a podobne, ale proste mi vyhovuje a uz asi 4 (mozna 5) let mi dobre slouzi. opakuju ze slouzi _mi_, tedy subjektivni posouzeni :-)
RE [26]: A až se jednou dostanete k programování na vyšší dívčí, tak zjistíte, že na ukládání dat nic lepšího než binární formát není. Prostě vezmete adresu objektu v paměti a sjedeteho do souboru (obyčejné bytecopy). A když ho znovu potřebujete, tak ho zase překopírujete do paměti a máte funkční objekt. Nepotřebujete žádný parser, metadata a tunu paměti. Geniální, co?
[26] "XML je moderni a je to moda, na tom urcite neco (mozna ne malo) bude."
A kde je nějaký argument, proč XML? Navíc móda je věc vrtkavá a ne vždy se řídící rozumem.
XML je hlavně nadužívané, nic víc a nic míň. A cpát XML do low level přenosového protokolu je pro mě čiré zoufalství. Protože nic, absolutně nic nepřináší, pouze bere. Je složitější implementovat XML protokol, než binární protokol. XML zabere několikanásobně více bajtů na přenos toho samého. U XML je složitější vzpamatovat se z chyby, než u binárního protokolu. XML je poměrně komplexní a jeho parsování není jednoduché a i když máte parser hotový, projeví se to na větší zátěži počítače - jste poměrně omezení v počtu přenesených a zpracovaných "XML paketů" za sekundu, což jsou limity, které jsou hodně důležité třeba u videa.
Znovu říkám, nevidím při použití XML protokolu v tomto případě pro IM protokol nic jiného, než nevýhody, nevýhody a zase nevýhody. Ani AOL není tak hloupá, aby založila svoje IM protokoly jako ICQ, AIM na XML - kromě dražšího provozu díky nutnosti mnohem většího počtu serverů, větší zátěže serverů, problémů s výkonem a sakra větším účtem za elektřinu i za hw a administrátory by nic nezískala.
Nehledě na tom, že znovu říkám, popadám se předem smíchy při pokusu přenášet video přes XML protokol. Zvláště třeba videokonferenci v reálném čase.
[27] Lojza "Prostě vezmete adresu objektu v paměti a sjedeteho do souboru (obyčejné bytecopy). "
Takhle nějak se ukládal .doc, ne? Sice nikdo (ani programátor) neví, co je uvnitř, ale to je jedno. (předpokládám, že ten tvůj komentář je ironie) Ještě že ti programátoři z MS mají vyšší dívčí :-)
[28] Miloslav Ponkrác
"A cpát XML do low level přenosového protokolu"
Chtělo by to znát aspoň nějakou teorii, než jen plácat nesmysly.
Chatování je aplikační protokol, což je v OSI úplně nahoře: http://cs.wikipedia.org/wiki/Referenční_model_ISO/OSI
"U XML je složitější vzpamatovat se z chyby, než u binárního protokolu."
XML dokumenty můžeme zkontrolovat (validovat) a zjistit, jestli jsou v pořádku nebo ne. Pokud nejsou, můžeme je zahodit a vyžádat si zprávu znovu. Protože taková chyba v dokumentu zcela jistě znamená chybu v aplikaci, která nám XML poslala. Chyby způsobené nekvalitními dráty nebo rušením wifi provozu jsou ošetřeny na nižší úrovni, proto od nich programátor aplikačního protokolu může abstrahovat. Je lepší, když aplikace neplatnou zprávu vrátí a vyžádá si novou (případně ohlásí chybu), než když se bude pokoušet o nějaké nestandardní nevyzpytatelné chování.
"XML je poměrně komplexní"
Složité je pro toho, kdo se ještě nenaučil používat vhodné nástroje, všem ostatním XML práci usnadňuje.
"jeho parsování není jednoduché a i když máte parser hotový, projeví se to na větší zátěži počítače"
Musím říct, že třeba přenášet data mezi transakčním systémem a datovým skladem pomocí webových služeb (založených na XML), by bylo naprosto zrůdné. Ale to ti nikdo nenutí, jsou ale oblasti (a že jich je), kde XML mnohem více přináší, než bere.
Jabber používám klidně i na mobilu, a to platím za každý přenesený kilobajt. Takže v pohoda.
"popadám se předem smíchy při pokusu přenášet video přes XML protokol."
Zase by si to chtělo něco přečíst:
http://www.xmpp.org/extensions/xep-0166.html#howitworks
"The negotiation takes place over XMPP, and the media transfer takes place outside of XMPP."
XMPP se použije pro dohodnutí spojení, ale následný přenos dat pak proběhne po jiném vhodném protokolu.
[29] Než začnu reagovat, mám pocit, že Vaše reakce jsou nepromyšlené a spíše emocionální, než aby v nich byla nějaká fakta.
"Chtělo by to znát aspoň nějakou teorii, než jen plácat nesmysly."
"Chatování je aplikační protokol, což je v OSI úplně nahoře: http://cs.wikipedia.org/wiki/Referenční_model_ISO/OSI"
A co jste tím chtěl říct? Kde je nějaká myšlenka? Na co vlastně reagujete?
"XML dokumenty můžeme zkontrolovat (validovat) a zjistit, jestli jsou v pořádku nebo ne."
Validace dokumentů = validace jejich struktury. Některé metody dokonce zkontrolují i některé typy. Ale kdybyste dokázal porozumět smyslu psanému textu, a dříve, než Vaše horká nepromyšlená hlava začne psát odpověď, kde mi to natřete - bylo by dobré si nechat od někoho poradit, jaký je rozdíl mezi "těžší" a "nemožné". Já jsem psal, že validace na úrovni XML je TĚŽŠÍ, nikoli, že nejde provést.
"Chyby způsobené nekvalitními dráty nebo rušením wifi provozu jsou ošetřeny na nižší úrovni, proto od nich programátor aplikačního protokolu může abstrahovat."
Ano, a žádné jiné druhy chyb neexistují :-)
"Je lepší, když aplikace neplatnou zprávu vrátí a vyžádá si novou (případně ohlásí chybu), než když se bude pokoušet o nějaké nestandardní nevyzpytatelné chování."
Ano, nejdříve ale musí poznat, že aplikace dostala neplatnou zprávu - a jsme zase u toho. A detekce chyb je vždy jednodušší i binárního protokolu. Povšimněte si prosím toho slova JEDNODUŠŠÍ - vzhledem k Vašemu horšímu chápaní psaného slova Vás na raději upozorňuji.
"....Ale to ti nikdo nenutí, jsou ale oblasti (a že jich je), kde XML mnohem více přináší, než bere."
Opět znovu musím apelovat na Vaši neschopnost chápat psané slovo. Bohužel. Pokud odcituji sám sebe, na co jste reagoval "při použití XML protokolu v tomto případě" - tak opět vidím, že nechápete slovní spojení V TOMTO PŘÍPADÉ - tedy pro Vaše vysvětlení hodnotím XML pro tento případ, je mi naprosto jasné, že jsou oblasti, kde XML je velmi vynikající věc.
"Zase by si to chtělo něco přečíst:"
A pak to porovnejte s řešením na úrovni jednoduchého binárního protokolu - a zjistíte, že je to asi tak 20x jednodušší na implementaci a mnohem bezproblémovější.
"XMPP se použije pro dohodnutí spojení, ale následný přenos dat pak proběhne po jiném vhodném protokolu."
Proč jednoduše, když to jde složitě. :-) Když se něco zmrví, tak se to pak zesložiťuje :-)
[30] Hmm, takže přenos dat mezi heterogeními systémy byl zaveden proto aby vznikla nová móda? Mám dojem že to bylo proto aby se zjednodušil a zpřehlednil přenos dat. Když vezmu jaké textové datové formáty se používají při přenosu dat do/z bankovních ústavů, je XML vysvobození. Proč pokaždé vyvíjet vlastní parser na kontrolu toho či onoho binárního formátu?!?
A propó je opravdu tak težké pohlížet na XML jako binární zápis jenom proto že je pro lidi čitelný?
Cely prispevok [30] mi pripada ako precitanie prvej vety prispevku [29], rychle preskrolovanie ocami a to je vsetko.. Nie som programatorsky guru, no pochopil som na co sa v [29] reaguje, dokonca som pochopil aj obsah, takze predpokladam ze chyba, pan Miloslav Ponkrác, bude niekde medzi Vasou stolickou a klavesnicou. Obycajne do diskuzi neprispievam, je pod moju uroven sa tu natahovat o zbytocnostiach, ktore su aj tak len v teoretickej rovine, no teraz som proste musel.
Ponkrac je starej znamej troubelin, ze ho jeste nekdo bere vazne? XML je velmi uzitecny univerzalni format pro prenos dat, ktery se rychle a siroce ujal. Tisice programatoru nezavisle na sobe jeho vyhody vidi, pouze Ponkrac i se svou dvacetiletou praxi nikoli a jeste ma potrebu to davat halasne najevo.
At si ten svuj bastl nechaji pro sebe. Je to sice hezke, ze to takhle uvolnuji, ale kdo se je o to zada? I kdyby byl nejaky gpl projekt implementujici dane podminky, klidne stravim par hodin tim, ze to z toho proste vykopu a budu to pouzivat a klidne to i uvolnim. Jinak myslim, ze xml pro im protokol je naprosto zbytecna vec. Naprosto.
[27] Jistě. Nejlépa tato metoda funguje pokud jsou součástí ukládaného objektu pointery. A pokud dostanu takovýto packet odněkud ze sítě, je nejlepší a nejrychlejší ho rovnou nakopírovat do příslušného objetku bez další kontroly, že?
A pak už jen při používání téhle aplikace čekat až někdo pošla po drátech nějaký shellcode a převezme kontrolu nad strojem :)
[38,39] A jaký máte důvod ho nepoužít? Chtěl bych slyšet konkrétní námitky proti použití XML právě v tomto případě.
Binární formáty - pěkně děkuji. Když se v protokolu objeví nutnost načítat datový typ, který v daném jazyce přímo neexistuje. A to už vůbec nemluvím o situacích, kdy jedna ze stran implementujících protokol udělá chybu. Představte si například situaci, kdy odesílatel vynechá jeden byte někde uprostřed zprávy. Jak se taková chyba v binárním formátu projeví? Jak se projeví v XML? Ve kterém z formátů rychleji pochopíte, co se stalo?
Pokud někoho trápí velikost přenesených dat, komprese přenášeného xml obsahu tento požadavek vyřeší podle mého názoru docela dobře.
Profesionální ajťák pracující pro korporát (narozen 1974). V soukromí však rád prosazuji svobodný software. Snažím se mít přehled o technologiích a trendech. Zastávám názor, že pokud chci něco kritizovat, musím s tím mít nějakou zkušenost. Jsem hrdý manžel, otec dvou dcer a opečovávatel kočky plemene Britská modrá krátkosrstá. Mám rád hudbu, knihy a kulturu obecně. V některých věcech však jdu proti proudu – používám Linux (konkrétně ZorinOS), svobodný software (LibreOffice, GIMP, Inkscape či Joomlu!) a jezdím v hybridním japonském autě.
Přečteno 47 162×
Přečteno 41 382×
Přečteno 35 909×
Přečteno 25 964×
Přečteno 25 765×