Ukázka WebGL - 3D grafika pro WebKit (diskuse)

[R]

Parada - 3D aplikacie v JavaScripte... To dava nove dimenzie slovu "pomale".

[Grunt]

Též nechápu co s tím furt blbnou. Znova.

[Jan Grmela]

Palm Pre, iPhone, Android...všechno WebKit. Už je to jasné?

[Grunt]

No moc ne. Spíš mi není jasné proč zas vymýšlejí znova kolo, když už je jich několik. Ba dokonce některé z nich standardizované. A nebo zas zkoušejí vymyslet jen další mrtvolku a doufají, že tentokrát už konečně.

[Mti.]

no, mi spis vadi nasledne nepochpeni moznosti takove technologie a jeji zneuzivani. Ted sedim na 4jadru, tak mi to nema co vadit, ale skryta predstava net/note/booku nebo mobilu s malou spotrebou a dlouhou vydrzi na bezne blbosti tak dostava zase dalsi ranu. :-/ Vetsina velkych serveru je v dnesni dobe zasekana bordelem, plno poskakujicich nesmyslu, vetsinou reklam, na Vanocni obdobi pravidelne alespon 5% stranek nasadi "snezeni" v js... zkouseli jste posledni dobou (co je maji idnes) blbe jizdni rady z neceho prenosneho? nez se dostanete k zadani odkud/kam, potaha Vam to pres megabajt(!) humusu. Kde zustala jednoduchost a lehkost puvodniho html?

[Grunt]

Kde zustala jednoduchost a lehkost puvodniho html?

Asi tam kde zůstalo VRML samotné.

[Mti.]

Asi nekomu vadilo, ze to neni "jejich" Taky, bohuzel, smutna praktika dnesni doby.

[helb]

zkouseli jste posledni dobou (co je maji idnes) blbe jizdni rady z neceho prenosneho? nez se dostanete k zadani odkud/kam, potaha Vam to pres megabajt(!) humusu. Kde zustala jednoduchost a lehkost puvodniho html?

Tady - idos.cz/blind.

[Mti.]

DIKYYYYY!

[...............23]

Tak imho lepšie než vo Flashi...

[slayn]

kde jsou ty časy, kdy web byl zdrojem informací? :(

[Ladicek]

Když jsme u toho, nikdy jsem nechápal, co kdo vidí na hypertextu jako způsobu prezentace informací. Lineární text mi prostě vyhovuje ze všeho nejlíp, takže celý web by patřil zrušit a ať se ksindli naučí pořádně se vyjadřovat.

A nebo ne, nejsem zpátečník a tmář: nechť se lidi klidně vyjadřují hypertextově. A nebo třeba trojrozměrnou grafikou, hypermédiím se meze nekladou (s výjimkou lidí v této diskusi, již by rádi sešněrovali web svou děsivou zkostnatělostí).

[mirec]

Áno, vyjadrujme textové infomácie vo flashi, 3D ... tak, aby sa všetci mohli dostať k informáciám. A najlepšie keď tieto veci využijeme aj na reklamu. Fakt pokrok, hlavne pre nevidiacich.

[Ladicek]

Nic jako "textové informace" neexistuje. Pro některé informace je vhodnou formou prezentace text, pro jiné 2D nebo 3D grafika (komu by se líbilo mít mapy v textové podobě?). Předpokládám, že to jste měl na mysli. Není chybou technologie, že ji lidé používají špatně.

[Marek Bernát]

A čo je to tá prezentácia? Nie je to tiež druh informácie? Podľa mňa je rozumné deliť informácie na textové/obrazové/zvukové, etc práve podľa toho, ktorá prezentácia je pre ne najvhodnejšia. A je nezmysel zobrazovať textové informácie vo flashi, alebo v 3D a/alebo naopak, čo je bohužiaľ presne to, kam tieto skvelé technológie vedú. Príchodom flashu sa nedosiahol žiadny posun v kvalite informácii, skôr naopak. Od 3D nečakám nič lepšie. Myslím, že si tu zaujal postoj teoretika principiálne otvoreného novým technológiam a ja postoj praktika, ktorý vidí, že v reále sú viac ako na hovno

[Ladicek]

A čo je to tá prezentácia? Nie je to tiež druh informácie?

Možná druh metainformace Ale informace lze sdělovat různými způsoby, ostatně i lineární text lze číst nebo slyšet (a třeba ještě statisticky zpracovávat za vzniku nové informace, ale tady už bych si musel osvěžit rozdíl mezi daty a informacemi).

čo je bohužiaľ presne to, kam tieto skvelé technológie vedú

3D technologie například zatím vedou k procházkám historickým Římem, Second Lifu a podobně. Že se to někdo (potisící) snaží dostat na web není překvapivé.

Ale v poslední větě máš asi velký kus pravdy

[Marek Bernát]

Ale aj metainformácia je samozrejme informácia v starom dobrom smalltalkovskom duchu

Hm, je to celé viac než trochu komplikované, to sa musí nechať. Ale aj tak si myslím, že informácie majú určitú povahu, napríklad textovú a zvuk a obraz reprezentujúci ten text je určený len na komunikáciu a inak nie je dôležitý. Aj keď kto vie. Ja keď niečo čítam, tak mi v hlave znie môj vlastný hlas, takže možno primárna reprezentácia textu je zvuková

Húmpf, ja som mal na mysli 3D v prehliadačoch. Ono je totiž strašne populárne tlačiť všetko cez HTTP, ktoré na to vôbec nebolo určené Niekto by sa mal zamyslieť, že čo sa chce vlastne dosiahnuť (zrejme multiplatformnosť a dostupnosť bez inštalácie) a vymyslieť trochu lepší spôsob, ktorý nebude zneužívať 30 rokov starý protokol na zobrazovanie textu

[Ladicek]

A v tom to je. HTTP prostě tak skvěle škáluje, že není problém ho použít pro ledacos, k čemu nebylo určené, a ono to funguje! To je jedna věc. A druhá věc – ty prohlížeče. Marná sláva, webový prohlížeč je dneska svého druhu "operační systém". Dost mě to děsí, ale vzdor propastným rozdílům mezi jednotlivými implementacemi je to asi nejširší aplikační platforma, kterou máme, takže se nedivím snaze na ni dostat věci na první pohled vysloveně šílené. Bohužel, vývoj pro ni je leckdy utrpením, ale rozumný programátor je buďto masochista nebo potenciální alkoholik už od úsvitu křemíkových dějin, takže se vlastně nic moc nemění.

A protože už jsme těžce off topic, tak bych to snad uzavřel

[Marek Bernát]

HTTP skvelo škáluje? Hahahaha, ďakujem za pobavenie 99% moderných webových aplikácií sa snaží HTTP nejak ohackovať, aby sa to podobalo na klasickú aplikáciu s GUI a TCP socketom a v 99% prípadov sa to zúfalo nedarí

Sme silne in topic, vzhľadom k tomu, že správička sa práve hackovania HTTP dosť týka, ale budiž, nechajme to tak.

[Ladicek]

Máš na mysli AJAX? To je úplně normální HTTP, přes které se přenáší třeba fragmenty HTML, data v JSONu, serializované objekty atd., akorát se požadavky vykonávají asynchronně. Sorry, to funguje úplně bez problémů na všech úrovních složitosti (od Taconite po GWT). Nebo máš na mysli Comet? S tím zkušenost nemám, ale zas tak často se to nepoužívá. Každopádně ani jedno z toho není hack, jenom neočekávané využití, kterému nic nebrání.

[Grunt]

Co? AJAX, že není hack neschopnosti protokolu HTTP, jo?

[Ladicek]

Jaké neschopnosti? Akorát se začaly posílat requesty v jiných situacích než bylo obvyklé, to je všechno.

[Grunt]

Ano, HTTP je vyloženě interaktivní protokol. Ba co jen samotné hlavničky tomu napovídají.

[xkucf03]

To, že ho někteří používají k věcem, ke kterým není určen, neznamená, že to je neschopný protokol – je to skvělý protokol pro přenos hypertextových dokumentů.

Pokud ale člověk potřebuje posílat data oboustranně, inicializovat komunikaci* i ze serveru, ne jen z klienta, není to vůbec vhodný protokol. V takových případech se mnohem víc hodí např. protokol XMPP nebo protokol, který si člověk napíše na míru (i když to je vštšinou zbytečné, protože se dá vystačit s existujícími protokoly, které umožňují oboustrannou komunikaci).

*) nemyslím inicializaci jako navázání nového síťového spojení, ale odeslání zprávy (volání metody, poslání dat…) v rámci již navázaného spojení.

[Grunt]

To, že ho někteří používají k věcem, ke kterým není určen, neznamená, že to je neschopný protokol – je to skvělý protokol pro přenos hypertextových dokumentů.

Dobrá, s tou neschopností jsem to asi přehnal, protože ano, HTTP je určen k něčemu jiného, zato svůj úkol plní na 100% a jen se ho někteří snaží využít/hackovat ve svůj prospěch a k tomu k čemu nikdy nebyl zamýšlen.

[Ladicek]

Pokud ale člověk potřebuje posílat data oboustranně

Ano, a proto neexistují metody PUT ani POST.

inicializovat komunikaci* i ze serveru

Ano, a proto nemáme persistentní spojení a HTTP server push ("Comet").

Já to vzdávám, zase dělám ďáblovi advokáta v off-topic flamu.

[Marek Bernát]

To teda robíš. Veď HTTP je hypertext protokol. Jasné, že sa dá využiť (a bohužiaľ zneužiť) na iné veci, ale snáď uznáš, že HTTP nenahradzuje TCP. Je to len jeden z miliónov protokolov nad ním a na webové aplikácie proste nebol určený a nehodí sa na ne. Už to, že je stateless ho robí bez hackov prakticky nepoužiteľným na hocičo iné ako jednoduché servovanie statického obsahu. Dynamický sa bez kontinuácií musí riešiť vždy redirectami a zasratým pageflowom a to je mi teda panečku škálovanie ako hrom

[Ladicek]

Že má HTTP v názvu slovo hypertext nic neznamená, to bychom po něm nemohli přenášet ani obrázky. HyperMedia Transfer Protokol? To by se u vás taky neujalo, to by připustilo tu 3D grafiku, fůj! UniverzálníTextovýProtokolJehožVelkáMnožinaPřípadůPoužitíJeZakázánaKomisíZTétoDiskuse? Go for it!

Mimochodem, jak se řeší stavovost v klient-server architektuře v situaci, kdy klient není důvěryhodný? Že by ponecháním stavu na serveru a přenosem nevýznamového tokenu? Aha, to nejde, to už se používá na webu, to je jistě špatně.

[xkucf03]

Klient je v tomhle smyslu nedůvěryhodný vždy – bez ohledu na to, zda je přihlášený či nepřihlášený a bez ohledu na komunikační protokol.

Kód klientského programu totiž běží na uživatelově počítači a uživatel může tenhle program pozměnit nebo ho úplně obejít a posílat pakety nebo příkazy ručně.

Jenže ten „nevýznamový token“ není u jiných protokolů potřeba kvůli tomu, že se drží jedno TCP spojení – spárování požadavků klienta pak funguje na základě toho, že všechny přišly stejným spojením.

Když spojení spadne, tak prostě nevíme, že to je tentýž uživatel, což u anonymních služeb nevadí* a u těch neanonymních se uživatel znovu prokáže jménem a heslem. Ve výjimečných případech, kdy chceme „indentitu“ konkrétního anonymního uživatele udržovat i v dalších síťových spojeních, tak prostě nějaký ten token použijeme – jenže u HTTP ho musíme použít vždy.

*) např. SMTP pro příchozí poštu, odesílající servery se nijak neprokazují, prostě pošlou maily pro naši doménu a my už si to nějak přebereme.

[Ladicek]

To je prostě ten asynchronní přístup. Implementovat synchronní protokol nad asynchronním je triviální (nevím, proč Marek výše tak naříká ), naopak stěží.

[xkucf03]

Vážně?

Asynchronní nad synchronním:

• pošlu požadavek a nepřijde odpověď (jen potvrzení, že byl požadavek přijat, že byla metoda zavolána, prostě void), ukončím metodu.
• z opačné strany je zavolána moje metoda pro příjem odpovědi (návratová hodnota je zase void).

Synchronní nad asynchronním:

• pošlu požadavek, metodu neukončím a čekám
• když přijde odpověď, vrátím hodnotu, která přišla a metoda skončí

Oboje vypadá stejně jednoduše, ale jen za jedné podínky: musí fungovat oboustranná komunikace – pokud totiž nefunguje, je druhá možnost (synchronní nad asynchronním) dost problematická – je potřeba v cyklu kontrolovat, jestli už přichází odpověď nebo zavolat metodu pro vyžádání odpovědi a metoda vrátí hodnotu až za dlouhou dobu (až je k dispozici odpověď), jenže tenhle přístup nám zase přidělává práci na „serveru“.

Zajímavý by mohl být snad leda ten „HTTP server push“, ale pokud nefunguje v MSIE, tak je v praxi nepoužitelný. A tady se dostáváme k další výhodě oddělení dokumentů a aplikací – pokud by vznikla nová platforma, vznikla by implementace nad jedním jádrem a nikdo by se nehádal, že chce používat třeba MSIE nebo Gecko – prostě by tu byla nejdřív specifikace a až potom implementace (časem by mohly vzniknout i implementace nad jinými jádry, ale musely by fungovat podle specifikace).

[Ladicek]

Synchronizovat se můžete třeba právě přenosem tokenu. Dokonce jsem viděl aplikaci, která odmítala druhý a všechny další požadavky daného uživatele (vyhozením výjimky), dokud nebylo dokončeno zpracování prvního, to je teprve stavová aplikace, hehe

[xkucf03]

Přijde mi, že každý pod pojmem „synchronní“ rozumíme něco jiného.

• asynchronní = posílání zpráv, MQ, SMTP… pošlu zprávu a ukončím zpravocání – odpověď přijde až někdy časem, do té doby pokračuji v jiné práci
• synchronní = volání metod, nebo HTTP – pošlu požadavek a čekám na odpověď – dokud nepřijde, nedělám nic (v daném vláknu).

takže moc nechápu, proč do toho mícháš nějaké tokeny – ty souvisí spíš se stavovostí protokolu, než s a/synchronním přístupem.

[Ladicek]

Jo, s tím asynchronním přístupem jsem neměl vůbec začínat, to byl z mojí strany blábol, který jsem v nějakém hnutí mysli spojil s bezestavovostí Omlouvám se, beru zpět.

Ale trvám na tom, že udělat na webu stav je prostě triviální, jak na serveru, tak na klientovi (jakkoli klient není důvěryhodný, interaktivita takové aplikace v GWT je úplně někde jinde než u typických request/response aplikací, a po HTTP se akorát přenáší serializované objekty; kontrola dat na serveru je nutná tak jako tak).

[xkucf03]

A udělat ze stavového bezestavový je nějaký problém? IMHO ne, sice se drží stejné síťové spojené, ale požadavky se zpracovávají bez ohledu na předchozí – prostě se ten stav zapomene (resp. se ani neukládá), což je skutečně bezpracné.

U HTTP by bylo fajn, kdyby se stačilo přihlásit jednou a dál fungovat v rámci jednoho „keep-alive“ spojení a žádný token by se nemusel posílat, protože by se vědělo, že je to pořád tentýž klient. Někdy se samozřejmě může hodit spojení přerušit a opět ho navázat, až když je potřeba (abychom neměli zbytečně moc otevřených spojení), ovšem tohle by chtělo implementovat na úrovni protokolu, ne až na úrovni aplikace. A ideálně to nevázat na konkrétní protokol (HTTP) ale vymyslet standard, který by vytvářel jakýsi abstraktní „socket“, který by se spojil, když je to potřeba a až nad ním by fungovalo HTTP, IMAP a další protokoly. (i když tohle přerušování spojení dost brání oboustranné komunikaci – push ze serveru).

A pak přidat (standardní) možnost oboustranné komunikace – sice je tu HTTP server push, ale MS o něm říká, že je to ošklivá proprietární technologie a že ji nebude podporovat.

Pak by byl HTTP celkem použitelný i pro jiné věci než prohlížení webů, ale i tam mi nepřijde vhodné cpát všechno do jednoho protokolu a provozovat na jednom portu. Např. při prohlížení webu vyžaduješ okamžitou odezvu, je to interaktivní práce, zatímco při stahování/odesílání souborů je ti celkem jedno, jak dlouho to trvá, nebo jestli se přenos na chvíli pozastaví, aby se udělalo místo něčemu interaktivnějšímu – jenže když se na všechno používá jeden protokol, je složitější tyhle priority řešit.

[Ladicek]

Neustále otevřená spojení jsou potřeba jen pro podmnožinu aplikací, zatímco pro jiné je to naprostý zabiják. A protože je stavovost doprogramovatelná tak triviálně (máte ji v každém frameworku, v Javě třeba je ještě níž) aplikačního programátora vůbec nemusí zajímat), je naprosto logické, že není součástí protokolu.

MS může o server push říkat co chce, ale v IE ho s jistým úsilím provozovat lze a Server-Sent Events jsou i součástí HTML 5. (A doufejme, že se vyplní nejmenované proroctví o tom, že MS prostě pod tlakem okolností HTML 5 implementovat bude muset )

Interaktivita prohlížení webu i práce s webovými aplikacemi je na úrovni běžného GUI (resp. dneska i pod ní, vteřinové zpoždění je pořád ještě akceptovatelné), to IMHO není potřeba řešit na úrovni protokolu, jak už jsem psal kousek níž.

[Marek Bernát]

Ach, takže to je univerzálny textový protokol. To znamená, že všetky ostatné protokoly nad TCP sú úplne zbytočné a pokojne by sa mohli nahradiť čisto HTTP...

[Ladicek]

No, tak jsem to úplně nemyslel. HTTP je přinejmenším velmi vhodné všude, kde je architektura založená na "zdrojích" (viz buzzword REST). Vzhledem k tomu, že ho lze bez problémů použít k přenosu jakýchkoli dat s minimálním overheadem (v podobě hlaviček, do kterých si aplikace navíc může uložit vlastní metadata), je jako stvořený pro komunikaci tenkých klientů se serverem (lhostejno, zda tam poteče HTML, program v programovacím jazyce nebo serializované objekty). Do real-time aplikací bych ho necpal, ostatně třeba takové MMO hry (to je vlastně soft real-time software) používají UDP

[Marek Bernát]

Ok. Lenže kde je tá hranica medzi real-time aplikáciou a klasickou webovou aplikáciou? Podľa mňa sa webové aplikácie pomaly ale isto dostávajú do štádia tých real-time a teda sa asi zhodneme, že HTTP je čím ďalej tým viac zneužívané.

[Ladicek]

No, některé webové aplikace mají interaktivní povahu (viz třeba předváděčku Google Wave ), ale neřekl bych, že zrovna HTTP je tady tím úzkým hrdlem. GUI aplikace jsou typicky vícevláknové, protože hlavní činnost vykonávaná v GUI vlákně prostě interaktivitu brzdí, a to na webu dodnes nejde. Proto jsou v HTML 5 ty Web Workers (a taky ty Web Sockets).

Shodujeme se určitě v tom, že některé aplikace cpát na web prostě nemá smysl. A když už se cpou do prohlížeče (Quake Live třeba, nebo OnLive, pokud z toho kdy něco bude), tak nemají s webem moc společného a opravdu určitě nepoužívají HTTP, s tím taky souhlasím.

[xkucf03]

HTTP se používá hlavně proto, že spousta blbů (administrátorů) na firewallech zakazuje cokoli jiného než TCP porty 80 a 443. A proto, že spousta jiných blbů (uživatelů) si pod pojmem Internet představuje jen web. Autoři aplikací se pak snaží vyhnout situaci, kdy uživatel má pocit, že mu „jde Internet" (dostane se na Seznam.cz)  ale naše aplikace „nejde a proto je tedy blbá“.

Nainstalovat si program není žádná  tragédie – tu z toho udělaly až Windows a uzavřený software.

Multiplatformní aplikace se dají psát třeba v Javě – a není potřeba je ani instalovat, stačí kliknout na jeden odkaz na webu, aplikace se sama stáhne a spustí – webstart. Bezpečnost je zajištěna pomocí SSL certifikátů a pomocí omezení aplikace (např. přístup jen k souborům, které vybral uživatel v souborovém dialogu, nebo jen z určité složky atd., i nesouborová omezení)

[Marek Bernát]

Presne. Práve preto som hovoril, že by nebolo od veci si sadnúť (napríklad páni od W3C) a zamyslieť sa nad protokolom, ktorý by umožňoval jednoduchú inštaláciu a multiplatformnosť, ale pritom nezväzoval ako HTTP. Ten webstart je dobrý príklad ako sa to dá robiť a IMHO presne tak budú webové aplikácie o 10/20 rokov vyzerať. Ale dnes sme bohužiaľ až po kolená v HTTP hackovaných sračkách

[Grunt]

Ten webstart je dobrý príklad ako sa to dá robiť a IMHO presne tak budú webové aplikácie o 10/20 rokov vyzerať.

Jen doufám, že aspoň bude aspoň z důvodu zpětné kompatibility i možnost přepnout si na dokumentovou reprezentaci.

[Marek Bernát]

Prečo? To nemôžeš s webstartom ani dnes. A úprimne, pri real-time aplikáciách si to neviem a ani nechcem predstaviť. Proste o pár rokov sa už budú používať len plnohodnotné webové aplikácie zhodné s tými desktopovými a na nejaký AJAX si nikto ani nespomenie. Aspoň dúfam.

[Grunt]

Tak jasně, u těch real-timeových aplikací mi to ani pořádně nejde. Hlavně u dokumentů. Teda v případě, že nebude nutné zobrazovat dokumenty skrze real-timové internetové aplikace. To bych se asi pak pěkně naštval.

[xkucf03]

dokument != aplikace

je potřeba rozlišovat mezi dokumentem (převážně text + obrázky + možná nějaký multimediální část, třeba 3D animace zobrazovaná pluginem) a aplikací, kterou jde těžko prezentovat jako text (jak převést třeba takový Gimp nebo chatovací aplikaci na text?).

Dneska v tom má dost lidí (i vývojářů) bordel – oboje se totiž zobrazuje ve webovém prohlížeči – ale jsou to dva diametrálně odlišné světy – mělo by zůstat klasické HTTP/HTML (pro dokumenty a prezentace) a vedle toho platforma pro „webové“ aplikace.

K tomu by mohla existovat možnost, jak vložit takovou aplikaci do webové stránky (jako se vkládají třeba obrázky nebo Flash) a s minimálními oprávněními by se ta aplikace mohla spouštět okamžitě – pokud by potřebovala oprávnění např. pro zápis na lokální disk, uživatel by byl dotázán, zda ji chce spustit.

[Grunt]

Dobře, oprava:

Tak jasně, u těch real-timeových aplikací přepnout do dokumentové reprezentace pořádně ani nejde. Ale Hlavně mi to(AJAX,flash,…) vadí dokumentů.

[Marek Bernát]

To je ale práve ta súčasná deformácia HTTP HTTP by mali byť proste hypertextové dokumenty a bodka. S aplikáciami by nemali mať nič spoločné a je desné, kam to zneužitie až došlo (a kam až dôjde?)...

[Grunt]

A patří vůbec real-timové internetová aplikace na HTML a HTTP? Fakt neexistuje nic lepšího?

[Marek Bernát]

Uh, to sme sa nejak nepochopili. Webstart predsa nefunguje cez HTTP, ale stiahne sa ti celá aplikácia na lokál, spustí sa ti v lokálnom VM a potom už komunikuje so serverom cez TCP socket. Takto si predstavujem webové aplikácie budúcnosti. Ale chce to nejakú jednotnú virtuálnu mašinu

[xkucf03]

Ono by šlo vytvořit podobnou, ale o dost lepší platformu, než jsou dnešní webové aplikace: na straně klinta by stále bylo nějaké jádro renderující XHTML + interpret JavaScript. Klient se serverem by komunikoval pomocí XMPP nebo jiného vhodného protokolu, místo HTTP. Aplikace by se šířila jako XML popis toho, co se má odkud stáhnout (XHTML, obrázky…) nebo jako ZIP obsahující tento XML popis + další soubory soubory – taková aplikace by mohla fungovat i offline. Programátor by mohl používat i nestandardní JavaScriptové funkce – např. pro přístup k místním souborům, práci s obrázky, kompresní a šifrovací algoritmy, práce s e-mailem atd. Aplikace by měla deklarativně nastavená oprávnění (např. že smí zapisovat pouze do ~/.aplikace1 atd.)

S tím by se daly psát mnohem lepší multiplatformní aplikace a hlavně by to bylo mnohem menší utrpení

[Ladicek]

Gratuluju, vymyslel jste HTML 5 Plus mínus. Offline aplikace jsou, datové úložiště na klientovi je (jak v podobě persistentní mapy, tak v podobě SQL databáze), drag'n'drop je, vlákna jsou, sockety jsou (a pozor, nad HTTP, chachá!), možná ještě nějaké další věci jsou, jenom to hrabání se na disku uživatele chybí (ono by to nebylo úplně triviální – autor aplikace není v tomhle zrovna důvěryhodný, a uživatelé jak známo na bezpečnost kašlou). Teda, jsou… jsou na papíře

[Marek Bernát]

Uh, tak to si budem musieť o HTML 5 doštudovať, vyzerá to ako najlepšia vec od krájaného chleba Doteraz som počul len <video> a mal som za to, že celý humbuk okolo HTML je len kvôli tomu Jednako však mám pocit, že to nebude zďaleka tak ružové, ako popisuješ.

[Ladicek]

No nebude. Už teď Microsoft implementuje client-side storage odlišně od specifikace (která, pravda, ještě není hotová)

[xkucf03]

Pořád to jede nad nevhodným protokolem (HTTP), autoři nebyli schopni se povznést a oprostit se od dogmatu, že aby něco bylo přenositelné a snadno nasaditelné, musí to fungovat nad HTTP.

Jsou aplikace a „aplikace“ – zatímco HTML 5 budou leda takové hračky, s tím mým návrhem by šly dělat plnohodnotné desktopové aplikace, které by ale měly podobné výhody jako webové. Taková aplikace by měla srovnatelné možnosti jako desktopová aplikace v Javě, akorát by se používal jiný jazyk a místo Swingu by bylo XHTML. A celé by to bylo „lehčí“ a přenositelnější (portovat někam jádro prohlížeče a interpret JS je snazší, než tam portovat celé JRE).

Ty nestandardní JavaScriptové funkce (např. pro přístup k místním souborům, práci s obrázky, kompresní a šifrovací algoritmy, práce s e-mailem atd.) by byly rozdělené do modulů a v XML popisu aplikace by bylo, jaké moduly vyžaduje – interpret na určité platformě by nemusel implementovat všechny moduly, takže některá aplikace by třeba fungovala na PC a nefungovala na starším PDA, ale věděl bys předem, jestli bude nebo nebude fungovat (podle požadovaných a poskytovaných modulů).

Další funkce by mohly být třeba přístup do osobních kontaktů, ke kalendáři atd. A díky deklarativním oprávněním by aplikace mohla jen to, co bys jí dovolil. Mohla by pracovat normálně se souborovým systémem a ne jen nějakým jedním souborem, který jí přidělí prohlížeč.

 

Teda, jsou… jsou na papíře

To je snad jediná výhoda HTML 5 – snad se stihne implementovat něco lepšího, než někdo procpe tenhle mizerný a omezený návrh

 

[xkucf03]

A hlavně bychom konečně odřízli (webové) aplikace od dokumentů – protože každé je něco úplně jiného

[Marek Bernát]

A je aj obyčajný formulár aplikácia, alebo nie? Teoretik vo mne hovorí, že áno, ale vieš si predstaviť, že v praxi niekto bude písať aplikáciu v XML + js, nastavovať jej práva, baliť ju a neviem čo všetko riešiť, keď stačí prachobyčajné <form> + PHP, ktoré je hotové za 5 minút? Ťažko, čo? Podľa mňa v tomto je zakopaný pes a dôvod prečo sa riešenia ako webstart nerozšírili nijak výrazne. Na drobné veci stačí HTTP + nejaký skriptovací jazyk a keď od nich chceš niečo viac, tak sa to tam proste dotlačí. Potom sa tomu dá meno Web 2.0 a všetko sa nahypuje a už to fičí

[xkucf03]

Ale vždyť HTML formuláře tu byly už dávno před AJAXem, na ty není potřeba žádná nová technologie, stačí pasivní HTML stránka + skript na straně serveru, který přijde GET/POST odpověď. Sice to není dokument, ale je to natolik triviální záležitost, že se dá bezbolestně implementovat nad HTTP.

[Marek Bernát]

Áno obyčajný formulár sa dá. A čo ak chceš overovať dáta, ktoré v tom formulári zadávaš (a ideálne na strane klienta)? Ani sa nenazdáš a máš z toho aplikáciu, ktorá na pozadí asynchrónne komunikuje Presne takto a nijak inak sa nám ten Web 2.0 mor rozšíril z obyčajných formulárov.

[Ladicek]

Jo jo. Slézt ze stromů byl prostě mizernej nápad.

[Marek Bernát]

Podľa mňa sme na tie stromy nemali vôbec liezť

[Ladicek]

To je snad jediná výhoda HTML 5 – snad se stihne implementovat něco lepšího, než někdo procpe tenhle mizerný a omezený návrh

Nebojte se, taková snaha už tu byla s XHTML 2, že se prostě vytvoří "nový web", který s tím starým nebude mít nic společného. Jak to dopadlo, všichni víme. A jak jsou na tom technologie typu JavaFX, Silverlight nebo Flex/AIR? No mizerně. Renesance appletů se nekoná a webstart se taky neuchytil. Jako nejpravděpodobnější směr v budoucnosti vidím GWT a příbuzné.

(Dyklamer: nesnažím se obhajovat špatné technologie, ale být realista.)

[xkucf03]

Vtip je v tom, že by to nebyl „nový web“, ale platforma pro aplikace. Nejblíž k té mé představě má asi ten XUL… až v HTML 5 půjde napsat něco jako Songbird, tak dej vědět

[Ladicek]

Vtip je v tom, takovou novou "webovou" aplikační platformu nutně potká stejný osud, jako ten nový web. Snění je to pěkné, což o to. Mně se zase nejvíc líbí JavaFX, ale to je prostě Sun, takže nad tím lámu hůl.

[Marek Bernát]

To ale, ak sa nemýlim, znie presne ako geckovský XUL. Je nad XML a robí sa v javascripte. Nie je to zlé na začiatok, ale oveľa bližšie k správnemu riešeniu má ten webstart. Fakt nevidím problém v tom stiahnutí aplikácie (ale tentokrát nie XML popisu, ale plnohodnotnej aplikácie v ľubovoľnom jazyku nad nejakým VM). Ostatne, už ten webstart by bol asi celkom v pohode, keby sa viac rozšíril a nahradil bežné aplikácie. Problém je, že sa ťažko definuje presná hranica medzi klasickým HTML formulárom a plnohodnotnou aplikáciou.

[xkucf03]

Nemám nic proti multimédiím (videu, 3D grafice, zvuku…) na webu, ale myslím, že by prohlížečům a vůbec webu prospěla větší modularita – většina věcí by se řešila přes pluginy (přičemž ty základní, to co se cpe dneska do jádra prohlížeče, by bylo v základní instalaci prohlížeče). Bylo by tak snadné např. vyměnit implementaci vykreslovače obrázků*, různé přehrávače videa, Flashe nebo 3D. Plugin by se vybíral na základě MIME Typu v HTML, nebo by si ho uživatel mohl definovat podle domény/stránky a typu. A chtělo by to nějaký registr pluginů a kompatibilitu pluginů mezi prohlížeči (aspoň v rámci jedné platformy).

*) neumí tvůj plugin průhledné PNG? nevadí, prostě ho vyměníš za jiný, který to umí a nemusíš měnit prohlížeč.

[Grunt]

neumí tvůj plugin průhledné PNG? nevadí, prostě ho vyměníš za jiný, který to umí a nemusíš měnit prohlížeč

Ono by bohatě stačilo kdyby i základní implementace obsahovali vše co standard nařizuje a doporučuje a pak by žádné plug-iny ani nebyly potřeba.

[Grunt]

Např. taková podpora standardu JPEG2000 trčí v Mozillý bugzille přes 9 let. A přitom už je předpřipraveno i hafo knihoven. A jediné řešení? Plug-in. Fakt paráda.

[xkucf03]

Na tom nevidím nic špatného. Prostě ta implementace vznikne jako plugin a až se časem ukáže, že je to dobré a že to lidi potřebují, dá se tenhle plugin do výchozí instalace prohlížeče.

Bylo by fajn, kdyby sis při stahování prohlížeče mohl naklikat, jaké pluginy v něm chceš mít (v Linuxu by to řešil balíčkovací systém) + by byla podobně snadná možnost instalace pluginů (ve Firefoxu: Správce doplňků / Zásuvné moduly).

[Grunt]

Ne, plug-in jednu nevýhodu má. Musí se nejdřív nainstalovat k něčemu k čemu je potřeba. A to mám jako někde vystavovat JPEG2000 a u toho nadpis: V případě, že používáte prohlížeč Firefox, prosím nainstalujte si tento plug-in. V případě, že používáte jiný prohlížeč máte smůlu. Co kdyby tak tomu bylo u JPEG samotného nebo třeba u PNG? To by byl oheň na střeše. Proti volbám samozřejmě nic, ale proti základním věcem, které mají být už implementovány v programu samotném jako plug-in ve Firefoxovském stylu už všechno.

v Linuxu by to řešil balíčkovací systém

Na co? Už několik dekád tady máme konfigurační volby ./configure skriptu.

[xkucf03]

 

Musí se nejdřív nainstalovat k něčemu k čemu je potřeba. … ale proti základním věcem, které mají být už implementovány v programu samotném

Psal jsem, že ty základní pluginy by byly už ve výchozí instalaci prohlížeče. Jak se to liší od situace, kdy tahle funkcionalita bude natvrdo zadrátovaná v prohlížeči?

 

Navíc nepotřebné pluginy můžeš vyházet, takže snížíš paměťové nároky nebo dobu spouštění – a každý za potřebné/nepotřebné považuje něco jiného.

 

A to mám jako někde vystavovat JPEG2000 a u toho nadpis: V případě, že používáte prohlížeč Firefox, prosím nainstalujte si tento plug-in.

Prohlížeč by instalaci daného pluginu měl nabídnout sám, na základě MIME typu uvedeného na stránce a na 1-2 kliknutí by ten plugin měl jít nainstalovat.

 

 

[Grunt]

Psal jsem, že ty základní pluginy by byly už ve výchozí instalaci prohlížeče. Jak se to liší od situace, kdy tahle funkcionalita bude natvrdo zadrátovaná v prohlížeči? Navíc nepotřebné pluginy můžeš vyházet, takže snížíš paměťové nároky nebo dobu spouštění – a každý za potřebné/nepotřebné považuje něco jiného.

Tato nosná myšlenka mi poněkud unikla.

Prohlížeč by instalaci daného pluginu měl nabídnout sám, na základě MIME typu uvedeného na stránce a na 1-2 kliknutí by ten plugin měl jít nainstalovat.

To souhlas. Ovšem nemění to nic na tom, že by se prvně standard musel implementovat.