Komentáře k článku

HTML5: První krůčky s FileSystem API

FileSystem API řeší jeden ze zásadních problémů webových aplikací, kterým je nemožnost pracovat se soubory v uživatelově počítači. S tímto API, které nabízí zatím jen Chrome 9, může webová aplikace vytvářet, číst, procházet a zapisovat do bezpečně vymezené části uživatelova souborového systému.

Zpět na článek

54 komentářů k článku HTML5: První krůčky s FileSystem API:

  1. ixi.80h

    bezpecnost

    … „do bezpečně vymezené části uživatelova souborového systému.“

    To znamena v praxi, ze to bude ukladano kam presne?

    1. Martin

      Re: bezpecnost

      Soubory budou fyzicky na disku, ale neni se treba obavat, ze by aplikace mohla pristupovat k celemu disku. Pouze k prostoru vymezenemu pro danou aplikaci.

      1. oxymoron

        Re: bezpecnost

        Chápal bych, kdyby to fungovalo podobně jako cookies, že by všechny soubory souborového systému prohlížeče byly uloženy v jednom TARu )nebo v několika TARech, přičemž každá apliakce by měla svůj TAR. V opačném případě je to zhovadilost, protože takovou „stránk-aplikaci“ by pak bylo vhodnější zkompilovat a nechat uživateli stáhnout a spustit lokálně, a opustit tak zbytečnou mezivrstvu – prohlížeč.
        Pokud toto FileAPI bude umět přistupovat k souborům přímo na disku, proti běžným apliakcím budu používat mezi vrstvy dvě – kromě prohlížeče ještě virtualizovaný OS, nejlépe běžící v jiném virtualizovaném OS, aby mi prohlížeč nemohl hrabat do mých souborů.

  2. Jerry

    Moc to HTML5 nechápu

    Tohle – a mnohem víc už umějí technologie jako Flash, Silverlight nebo Java applety – všechny uvedené technologie mají použitelné GUI, nekonečné možnosti rozšíření A HLAVNĚ chovají se ve všech prohlížečích stejně. Čili k čemu je dobré se sr..t s Javascriptem a jeho bambilionem rozšíření typu jQuery? Kdo s tím OPRAVDU pracoval a dělalo mu to radost ať hodí kamenem :)

    1. lol

      Re: Moc to HTML5 nechápu

      java, flash, … vsetko genialne sposoby ako vytazit jadra cpu na max tymi najprimitivnejsimi funkciami … a to sa vyplati :)

      1. tik

        Re: Moc to HTML5 nechápu

        Kdyz si vzpomenu, co s mym x2 amd delal HTML5 stromecek tady na vanoce, tak tohle neni ten nejlepsi argument ;)

        1. lol

          Re: Moc to HTML5 nechápu

          asi som tu cez vianoce nebol alebo ten stromecek bol prehliadnutelny … v kazdom pripade porovnavat html5 ktore este nema plnu podporu v prehliadacoch (o hw akceleracii ani nehovorim) a flash ktory tu je uz od roku 1996.
          Odhliadnuc od toho – pouzit flash na pracu s lokalnymi subormi je ako pouzivat kamion s privesom o nosnosti 20 ton na prevazanie jedenj palety. Samozrejem ze to ide, ale to mrhanie prostriedkami…

        2. Martin Malý

          Re: Moc to HTML5 nechápu

          Vzpomínaný stromeček (3D rotující vánoční stromek s chumelenicí) byl především „1kB demo“ – tedy ukázka, že takovou věc lze zmáčknout do kilobajtu zdrojového kódu, nikoli ukázka použití HTML5. Tím je také dané, kam autor napřel optimalizační síly. Brát to jako příklad (nebo dokonce „typický příklad“) HTML5 je nesmysl. U reálného řešení by nikdo nepoužil takový postup a nemačkal by to do 1kB kódu, ale vzal by WebGL, a vy byste si, díky HW akceleraci, ani nevšiml, že nějaký procesor máte. :)

          1. tik

            Re: Moc to HTML5 nechápu

            naprosto souhlasim. Bylo to jen poukazani na nesmyslnost argumentu, ze jen ostatni technologie vytezuji procesor na 100(200, 300)%.
            A protoze mi tu ted nic nehuci, jdu hledat, kde a zda mam ten procesor ;)

            1. koroptev

              Re: Moc to HTML5 nechápu

              takze ten interpretovany kod, ktery tusim delal neco s canvasem, nevytezuje cpu nasobne vicekrat oproti nativni aplikaci?

        3. tom-tom

          Re: Moc to HTML5 nechápu

          S tou optimalizací a vytížením procesoru to celkově u HTML5 nebude žádná sláva. Podle mě, buďto se zatím nikdo nesnaží optimalizovat, nebo to prostě zatím vůbec nejde.

          O silverlightu toho moc nevím, instalaci pluginu do prohlížeče se zuby-nehty bráním, pokud stránka nejede bez něj, prostě ji nemusím vidět a všechny flashe, ať už jde o hry na mojehry.cz, přes flashové stránky až po ty stupidní bannery mi na obou ntb jedou, aniž by se procesor nějak výrazně zapotil.

          Ukázek v HTML5 jsem vyzkoušel několik a musím říct, že z žádné jsem neměl moc dobrý pocit, co se týče zátěže systému.
          A konkrétně ten vánoční stromeček, s tím mi šel procesor tak vysoko, že se mi rozběhl na notebooku ventilátor naplno, což se jinak neděje moc často.
          No a ta ponorka na googlu u příležitosti narození J.Verna, ta mi na prvním notebooku jela sice plynule, ale zátěž šla hrubě nahoru a na druhém ntb, s kterým běhám po klientech, tam jsem musel změnit ten den homepage, protože ta „slideshow“ mi tak umrtvovala prohlížeč, že jsem ho musel natvrdo killnout.

          A moje osobní pohnutky – ve flashi umím (poctivý actionscript, ne tahání tvarů po sandboxu :) a nedokážu si představit, že bych měl někdy totéž dělat v paskvilu, jako je HTML5, byť by měl 100% hw podporu v jádře procesoru nebo grafické karty ;)

          1. Martin Malý

            Re: Moc to HTML5 nechápu

            Mrkněte na EaselJS, brzy o něm napíšeme i tady. EaselJS je knihovna, která funguje podobně jako flashový API (stage a spol.) Přistupujete k němu z JS, což je v základu stejný ECMAScript jako AS.

            Sice to opakuju asi už poosmé, ale holt někomu není dáno rozumět psanému textu: Vánoční stromeček je 1kB DEMO! Demonstrační kód optimalizovaný za hranici běžného použití tak, aby se vešel do 1kB! Principem 1kB dema není ukázat, co technologie umí a jak funguje, ale co umí programátor, a je jasné, že takové demo, omezené v jednom směru (1kB kódu) bude neoptimální v jiném. Zajímalo by mne – ten rozdíl proti normálnímu kódu pochopit nedokážete, nebo nechcete?

            1. pas

              Re: Moc to HTML5 nechápu

              Nekteří lidé mají evidentně pocit, že dobrá technologie má prostě programátorovi zakázat, aby roztočil větráček na maximum. Zvlášť, když je to vlastně jen takový jednoduchý animovaný obrázek, že? No, ruku na srdce – praxe bude často vypadat tak, že kód bude mít sice 50 KB místo 1 KB, ale nárok na výkon bude stejný. Flashaři vědí… (i tam nastupuje HW akcelerace jako ve WebGL, ale kdy se o tom dozví armáda znuděných tvůrců reklam?)

              „… JS, což je v základu stejný ECMAScript jako AS.“ – přesněji řečeno jako AS1 (flashaři opět vědí… jaké pocity a vzpomínky mají vyplout na povrch… :))

            2. tom-tom

              Re: Moc to HTML5 nechápu

              Měl jsem přečtenou celou diskusi, než jsem něco napsal, takže mám přehled o tom, kolikrát se tady psalo, že stromeček byl demo.
              Proto jsem jako druhý příklad zmínil ten google, protože tam to rozhodně demo nebylo – je rozdíl publikovat něco takového na zdrojáku a na googlu, který má podstatně větší návštěvnost, že :)

              Je sice fajn, že stromeček šel natlačit do 1kB, ale k čemu je to dobrý, když je omtimalizace tímto směrem kontraproduktivní a nakonec to polovině lidí nejede. A razit to jako demonstraci, že jenom v HTML5 to jde udělat z jednoho kilobajtu, to mu moc na reputaci nepřidá.
              Jasně, ve flashi by šla taková věc natlačit řekněme do 5kB, ale pojede to i na founu s androidem, nebo netbooku s Atomem.

              A už vidím, jak vysvětluju zákazníkovi: „ehm, no… tak máte to v HTML5, což je dneska IN, objem dat je 5x menší než u flashe, takže se to bude rychle načítat i na mobilním internetu, ale zatím to jede plynule jen na nejrychlejším superpočítači v USA a na druhém nejrychlejším v Číně to občas zadrne… ale to se do 10ti let změní“ :)

        4. František Kučera

          Re: Moc to HTML5 nechápu

          +1, taky si na ten hororový stromeček pamatuji, moc dobrou reklamu HTML5 neudělal.

          Co se týče Java appletů – jejich nevýhoda je trochu pomalejší start a fakt, že je to cizorodý prvek na stránce (to se týká všech pluginů), ale s výkonem a zmiňovaným vytěžováním CPU není problém.

          1. Martin Malý

            Re: Moc to HTML5 nechápu

            „Je to demo, je to technologické demo, je to jednokilové demo, je to technologická pikantérie, jednokilové demo, je to demo optimalizované na velikost, je to JS 1K demo, je to demo, …“ 1kB dema nejsou ukázkou technologie, ale ukázkou programátorské virtuozity, asi jako lodě v láhvi nejsou reklamou na loděnice, ale na klidnou ruku…

            1. tom-tom

              Re: Moc to HTML5 nechápu

              Jo takhle… tím se to vysvětluje. Omlouvám se za svůj předchozí příspěvek, kde jsem se ptal, k čemu je 1k demo dobrý.
              Vím, že taková věc dala programátorovi spoustu práce.. a přitom taková blbost, že? :)

              Jako, pikantérie to jistě je, ale HTML5 takové věci (prozatím) nedělají moc dobré jméno. Alespoň na tomhle se jistě shodnem.

              1. Martin Malý

                Re: Moc to HTML5 nechápu

                Přesně tak. Spousta práce, a přitom taková blbost… :) Vytváření podobných příkladů je cvičení pro programátory, taková frajeřinka – není to pro praktické použití, ale je to hlavolam, nad kterým ostatní programátoři řeknou Hmmm… Zajímavé jsou na tom hlavně optimalizace algoritmů, které člověk dělá.

                Navíc – byly svátky, chtělo to nějakou „blbůstku“ na odlehčení.

                Mimochodem, víte co je pěkné? Že celý ten stromeček byl čistě JS, z HTML5 použil jen canvas, což je vykreslování do bitmapy. Takže ti, co říkají, jak to je špatná ukázka HTML5, vlastně ukazují, že netuší o čem hovoří – protože šlo o algoritmy v JavaScriptu, ne o HTML5. Ostatně – pokud si to demo pustíte v Chrome, které má hyperrychlý JS, na problém s výkonem nenarazíte.

            2. František Kučera

              Re: Moc to HTML5 nechápu

              Ale to si neprotiřečí.

              1) zážitek to byl „hororový“ (dobře, možná trochu expresivní slovo, ale to snad nevadí), protože mi nezvykle zatížil procesor – na jiných webech se mi tohle nestává (Flash jsem odinstaloval).

              2) Moc dobrou reklamu HTML5 to neudělalo – ačkoli si teď matně vzpomínám, že to bylo 1kB demo, v první řadě ho mám spojený s HTML5 jako takovým a zjevně v tom nejsem sám – z reklamy nikdy neutkví v hlavě všechno a informace, že jde o HTML5 byla jaksi výraznější, než ten 1kB.

    2. Pavel Šimerda (pavlix)

      Re: Moc to HTML5 nechápu

      „A HLAVNĚ chovají se ve všech prohlížečích stejně“

      Tedy, buď nefungují (a jde doinstalovat plugin), nebo nefungují (a plugin není).

  3. VM

    děkuji nechci

    Neznám žádný rozumný důvod proč by měla webová stránka přistupovat na můj filesystém – tedy s výjimkou spyware a malware. Na posílání dat je HTTP POST (který tohle vzhledem k omezené částí FS stejně nenahradí), a když mi web chce nějaký soubor poslat, tak si ho radši uložím ručně kam chci sám.

    Myslím že znásilňovat prohlížeč aby poskytoval všechny funkce operačního systému _není_ dobrý nápad.

    Napadá mě jediné – až to bude ve Firefoxu, jak to vypnout?

    1. imploder

      Re: děkuji nechci

      Už nemáme jen webové stránky, máme webové aplikace. Možnost přístupu k filesystému je důležitá, bez toho je spousta aplikací jak bez ruky.

      1. František Kučera

        Re: děkuji nechci

        Bude to znít ošklivě, ale: možná je právě tohle čas naučit se programovat a dělat normální aplikace – místo ohýbání prezentační/ob­sahové platformy.

        1. imploder

          Re: děkuji nechci
          Ve webové aplikaci vidím určité výhody:

          1. bezpečnost: můžu bez rizika (pokud nemám děravý prohlížeč) pracovat i s nedůvěryhodnou aplikací
          2. nemusí se instalovat, je okamžitě k dispozici
          3. multiplatformnost: funguje, ať už uživatel používá Windows, Linux, MacOSX nebo třeba PlayStation nebo nějaký mobilní systém

          Je mi jasné, že na některé aplikace je web nevhodný. Na některé jiné je ale použitelný dobře (nebo by s ne moc rozsáhlými úpravami mohl být). V současné době se hodně prosazují webové aplikace, ty 3 výhody, co jsem zmínil, můžou být podstatné. Spousta věcí se dělá jako webová aplikace. Kolik z nich nabízí dobrou integraci s offline desktopem?

          Nejde jenom o upload. Některé věci se dají udělat offline v javascriptu. Prohlížeč může sloužit jenom jako zavaděč programu z internetu, se všemi třemi zmíněnými výhodami. Javascript v prohlížeči a HTML5 je určitým způsobem výhodná platforma. Pokud to má k něčemu být jako opravdová aplikační platforma, nesmí být problém s takovou trivialitou jako vzít si od uživatele soubor(y) a nějak ho/je zpracovat.

          Není to o tom, v čem já umím nebo neumím programovat.

          1. VM

            Re: děkuji nechci

            Ad 1. – čím více podobných „featur“ typu přístup do filesystému, tím hůře s bezpečností. Ta stavěla hlavně na tom, že prohlížeč je záležitost prezentační nikoliv výkonná, která zpracovává hodně omezený kód. To se teď má omezovat. Prohlížeče děravé jsou, bezpečnost půjde do kytek.
            Ad 2. – ano, na druhou stranu při výpadku připojení na tom jste daleko hůř než s aplikací co se musí instalovat
            Ad 3. – multiplatformnost je hodně omezená – třeba popisovaná featura je pouze v Chromiu. O tom co funguje/nefunguje v IE by vývojáři mohli psát romány. Navíc závisí na pluginech, velikosti okna… Samozřejmě je to multiplatformnost přes prohlížeče, nikoliv přes OS.

            Nejsem apriori proti webovým aplikacím, ale nevidím v nich žádný zásadní přínos. Jak říká Peterka, vývoj se pohybuje ode zdi ke zdi, a všechno to tu už bylo – vzpomeňte spouštění programů na dálku přes terminály a X, když se pak přešlo na programy instalované přímo na počítači, tak se to bralo jako velký pokrok – člověk měl všechno pohodlně u sebe.

            1. imploder

              Re: děkuji nechci

              S tímhle souhlasím, až na tu nevyhnutelnost bezpečnostních děr v prohlížeči. Fakt je, že webové aplikace se nedají použít zdaleka na všechno a jako aplikační platforma je web takový kočkopes, ale na některé věci je to nejlepší možná volba. HTML5 přináší vylepšení především pro webové aplikace. Pokud se rozhodneme webové aplikace celkově ignorovat, tak nemá smysl zabývat se HTML5 a číst tenhle článek.

              1. Martin Malý

                Re: děkuji nechci

                Tak zrovna nevyhnutelnost chyb mi připadá jako nejneoddiskuto­vatelnější (fuj, co jsem to napsal?) Tedy že je téměř jisté, že se nějaká chyba v implementaci objeví.

                1. imploder

                  Re: děkuji nechci

                  Nějaká chyba ano, ale nemusí to být chyba, která způsobí, že někdo cizí získá přístup k systému. Třeba u firefoxu jsou takové kritické chyby typicky způsobené chybnou prací s pamětí.

                  Proč by zrovna to, že si uživatel může vybrat soubor, který předá javascriptové aplikaci, mělo vadit? Čím je to nebezpečné?

                  1. Oxymoron

                    Re: děkuji nechci

                    Pokud by uživatel chtěl předat Javaskriptu soubor, nemusí jakési souborové rozhranní být potřeba, na to by stačilo rozšířit INPUT TYPE=“file“ např. na INPUT TYPE=Javascrip­tfile, kdy by si prohlížeč vytvořil kopii souboru, ke které by mohl javaskript přistupovat.
                    Ale nechat webovou stránku hrabat na lokální disk, je zvěrstvo.

                    1. imploder

                      Re: děkuji nechci

                      Pokud se to „hrabání“ bude dát omezit jen na čtení, tak jaký je v tom rozdíl, kromě toho, že se zamezí zbytečnému kopírování dat souboru speciálně pro skript?

                      1. pas

                        Re: děkuji nechci

                        Přesně tak a stačí se inspirovat u flashového FileReference API, kdy uživatel jak pro čtení, tak pro zápis vybere pomocí systémového dialogu cestu k souboru a s ním pak samotné čtení/zápis provádí skript. Navíc je to posichrováno tím, že tato operace musí být vyvolána přímou interakcí uživatele (volání z click handleru, apod.), nikoliv iniciována skriptem. To přece musí (spolu s lokálním úložištěm) plně stačit pro webové aplikace.

                        1. Oxymoron

                          Re: děkuji nechci

                          Za jak dlouho někdo přijde s tím, že je to zbytečné omezení a že by fleš měl mít plný přístup k souborovému systému? Pamatuju doby, kdy fleš byl jenom pro animace. Po té, co jsem u jedho flešového chatu viděl obraz z mojí webkamery, fleš jsem odinstaloval a od té doby ho neinstaluju.

                          1. pas

                            Re: děkuji nechci

                            Pamatuju doby, kdy HTML bylo pro publikování článků, něco jako teletext. Od té doby, co jsem viděl v HTML Google Apps, jsem to odinstaloval. ;-)

                            I když není moc v módě přiznávat, že Flashem by bylo vhodné se občas inspirovat, osobně si myslím, že systém bezpečnosti a soukromí je v něm navržený velmi dobře (nemluvím o bugách, kterými je také proslulý, ale o koncepci). Například zmíněný přístup k webkameře jste zcela jistě musel osobně povolit pro danou doménu.

                            1. Martin Malý

                              Re: děkuji nechci

                              Jak že se přesně jmenovala ta technika, která přes Flash natáhla div, takže člověk klikal, aniž by tušil, že pod tím je dialog Flashe na povolení práce s kamerou, a kvůli které je teď Flash vždy před všemi objekty na stránce? Jo, už vím – clickjacking… ;)

                      2. Oxymoron

                        Re: děkuji nechci

                        Pak je jenom otázkou času, kdy někdo přijde s tím, že je to zbytečné omezování a přijde se zápisem. K čemu je dobré, když Javaskript bude umět přistupovat k souborovému systému? Aby Javaskript mohl prohledat můj adresář a odeslat Gůglu moje soubory?
                        Už dneska jsou lidé před některými stránkami varováni, protože se nechovají zcela korektně. Zatím je to dost omezující, protože takové stránky musí využít chyby prohlížeče. Ale nevidím žádný rozumný důvod, proč přístup k počítači takovýmto stránkám usnadňovat.

                        Mimochodem:
                        a) v době, kdy po netu lítají zbytečné gigabajty dat (spam, apod.), tak bych několik kilobajtíků poslaných navíc neviděl jako problém. Je to prostě cena za větší bezpečnost. Kdyby se v paketech odstranily kontrolní součty, taky by se pát megabajtů ušetřilo.
                        b) Javaskript se k lokálním souborům bez kopírování přes síť dostane i dnes. Stačí využít Ajax a lokální webserver. Je to rychlé, spolehlivé a bezpečnější než přímý přístup prohlížeče, uživatelé si jenom museli zvyknout, že zpracovávané soubory se musí zkopírovat do jednoho konkrétního adresáře.

                        1. imploder

                          Re: děkuji nechci

                          Pokud si budu přát, aby mi skript prohledal adresář a odeslal Gůglu moje soubory, tak ano, bude to možné. Pokud si to přát nebudu, tak se nic takového samozřejmě nestane. Je samozřejmě potřeba to implementovat bezpečně, stejně jako zbytek prohlížeče.

                          Proti zápisu nic nemám, jen by se to měl od čtení rozlišovat. Ani jedno z toho (čtení ani zápis) by se nemělo dít bez vědomí uživatele a obojí by mělo s vědomím uživatele bezproblémově jít.

                          K bodu a:
                          Zbytečné lítání věcí po síti nemá s bezpečností nic společného, je to důsledek toho, že se webové technologie používají na něco, na co nejsou moc dobře uzpůsobené, protože se s takovým použitím původně nepočítalo.

                          K bodu b:

                          1. Je to nepraktický hack. Aneb na co mít ruce, když si můžu přivázat k noze smeták a drbat se za uchem jím?
                          2. Místo přímého přístupu prohlížeče máme přímý přístup skriptů na lokálním webserveru (ty mimochodem musíme nejdřív nainstalovat a musíme jim věřit). V čem je to bezpečnější? Já v tom teda vidím spíš větší nebezpečí, může se tam podělat víc věcí než jen prohlížeč.
                          1. Oxymoron

                            Re: děkuji nechci

                            To je právě to. Bezpečná implementace neexistuje. Jediná bezpečná implementace je vlastní odstíněný souborový systém, např. v TARu nebo ZIPu.

                            ad a) Zbytečné lítání dat po síti je daň za bezpečnost, aby webová stránka nemohla přistupovat neomezeně k jakýmkoliv souborům, ale pouze k těm, které výslovně vybere. Navíc není přistupováno přímo k souborům, ale k jejich kopiím, což je podle mého názoru bezpečnější. Jenom je to nepohodlné. Vidím to podobně jako PIN u platební karty, bez něj by užívání karty bylo také mnohem pohodlnější.

                            ad b) Bezpečnější je to v tom, že onen lokální server je možné vypnout a prohlížeč tak nemůže přistupovat k ničemu. Dále onen webový server může běžet na jiném počítači. Je tak zajištěno, že webová stránka nebude přistupovat k tomu, k čemu nemá. A vzhledem k tomu, že webových serverů existuje více, těžko může nějaká webová stránka předpokládat konkrétní chybu implementace v kombinaci prohlížeč + webserver.

                            Mimochodem, když už prohlížeče obsahují kompiler, proč by webové aplikace nemohli fungovat tak, že by se stáhnul zdroják, vytvořil by se .exe či jiný spustitelný soubor, který by si pak uživatel manuálně spustil?

                            1. imploder

                              Re: děkuji nechci

                              Pokud budeme potřebovat celé adresáře (ne jen jednotlivé soubory), tak bude potřeba zajistit, aby javascript nemohl z adresáře „utéct“, to je pravda. TAR nebo ZIP by šel, ale lepší by bylo řešení, kde se takový odstíněný souborový systém namapuje na kus opravdového filesystému. Tohle by asi nebylo nutné, implementace omezující přístup programů na určité soubory nebo adresáře existují, viz AppArmor.

                              ad a) Že stránka nemůže přistupovat k jakýmkoliv souborům, ale jen k vybraným, je snad jasné. Platilo by to i kdyby se dalo přistupovat k souborům javascriptem. Lítání po síti k bezpečnosti nepřispívá, právě naopak: přílišná komunikace s okolím bezpečnosti škodí, aplikace je pak hůř ověřitelná, má víc potenciálních vektorů napadení; dobré pro bezpečnost je omezit rozhraní s okolním světem na minimum.

                              ad b) Aneb výhoda modularity. V dnešní době, kdy Chrome má pro každý tab oddělený proces, by určitě nebyl problém implementovat i práci se soubory jako oddělený proces. Je to otázka implementace. Běh na jiném počítači, to je na věc sloužící k přístupu k lokálním souborům dost neobvyklý požadavek. Dává to smysl, je to dobré pro bezpečnost – tím, že se na každá data/činnost používá jiný počítač. Znamenalo by to vyhradit další počítač pro přístup javascriptů z webu – bylo by tam jen to, co je potřeba. Bezpečnost provozu jakéhokoliv programu se zlepší tím, že se mu vyhradí zvláštní počítač. Naprostá většina lidí by ale IMHO něco takového nevyužila; taky je možné řešení, že prostě člověk používá na prohlížení webu zvláštní počítač nebo aspoň zvláštní uživatelský účet – není potřeba a podle mě ani není vhodné, aby si to řešily prohlížeče nebo dokonce přímo webové aplikace sami.

                              Kód z webu běžící přímo jako nativní kód – takový projekt existuje, dokonce ani nepotřebuje, aby prohlížeč program z nějakého jazyka překládal. Jmenuje se to Native Client a mělo by to umožňovat spustit v bezpečném sandboxu strojový kód x86 z internetu.

                              1. Oxymoron

                                Re: děkuji nechci

                                No … a dostali jsme se k tomu, že pokud by aplikace měla něco ukládat na lokální disk, tak je na to lepší lokální aplikace, protože dnešní OS už na věci spojené se zabezpečením nástroje má. Pokud by se uživatel bál, že program něco někam odesílá, může ho jednoduše (alespoň ve Windows) odstřihnout od sítě. Pokud by to bylo jenom o stažení zdrojového kódu a otevření ho v nějakém programu, bylo by bezproblémové.

                                Možná jsem ze staré školy, ale smysl webové aplikace, která by si načítala data z uživatelského počítače a výsledek mu jako soubor ukládala na jeho počítač mi uniká. Stejně tak mi uniká smysl toho, aby server podstrkával už načtené stránce, aby něco udělal.

          2. Oxymoron

            Re: děkuji nechci

            1. Bezpečnost webové aplikace jde do kytek, když apliakce může přistupovat k souborovému systému.

            2. Existují i běžné programy, jteré se nemusí instalovat, stačí je pouze zkopírovat a spustit.

            3. Jak už někdo psal, multiplatformnost je narušitelná odchylkami v interperetaci/kom­pilaci Javaskriptu. Takže místo požadavku na OS budou požadavky na prohlížeč. Nebo napsání více variant pro různé prohlížeče, což je ekvivalentní situaci více variant programů pro různé OS.

  4. koroptev

    kruh se uzavrel

    zbyva doresit, aby se kazda www stranka zobrazovala v samostatnem okne a vypadala jako nativni aplikace systemu..

    ..a budeme zazivat vyhody toho, ze jsme se konecne dohodli na jednom globalnim celosvetovem api pro psani nejen DEMO stromecku, zel asi tak 20 vrstev nad hw

  5. imploder

    Soubory vybrané uživatelem

    Je v plánu možnost dát uživateli na výběr, který soubor nebo adresář tomuhle API poskytne? Bez toho nejde přistupovat k souboru, který nevytvořila stejná webová aplikace. Je to hodně důležitá věc pro integraci webových aplikací a offline aplikací, které pracují se soubory ve filesystému. Zatím jediná možnost jak předat soubor z disku webové aplikaci je vybrat ho ve formuláři a poslat ho na server přes POST – to je v případě, že s těmi daty pak bude pracovat JS kód v prohlížeči, naprosto nesmyslné kolečko klient-server-klient.

    1. Oxymoron

      Re: Soubory vybrané uživatelem

      Na jednu stranu se brojí proti tagu FONT (ještě mi pořádně nikdo nevysvětlil, jaký je rozdíl mezi zápisem FONT COLOR=“red“ a SPAN CLASS=“red“ … obojí by dělalo to samé, jenom ta druhá varinta zabírá víc místa) a pak se přidá hrabání stránek na disk. K čemu webová prezentace potřebuje hrabat na disk?

      1. Nox

        Re: Soubory vybrané uživatelem

        1. Ad font x span
          • .red je relativně univerzálnější, jde upravovat význam, třeba odstín, napříč aplikací LEČ
          • tenhle zápis je minimálně dost ošemetný ne-li špatný. To, že nevidíte rozdíl je trochu správně, takto se to totiž zapisovat nemá, nemají se volit jména tříd podle jejich momentálního vzhledu, ale podle účelu (tzn. místo .red například .highlight-strong)
        2. Tady opět je docela špatně položená otázka – jasně, webová <b>prezentace</b> se nemá hrabat v disku, jenže pokud ve své otázce smrsknete všechny weby jen na jejich prezentační vrstvu … webová aplikace už by nějaký důvod mít mohla
        1. Oxymoron

          Re: Soubory vybrané uživatelem

          Ad 1)
          Ano souhlas – pokud je cílem červené písmo daného odstínu, tak bych viděl pojmenování red zcela v pořádku. Někdy je to ne kvůli nějakému zvýraznění ale prostě proto, že je to vzhledově lepší. Nebo třeba použití třech různých zvýraznění na stejné úrovni zvýraznění … to bych je měl pojmenovat třeba jako .zvýraznění1-silné, zvýraznění2-silné, . zvýraznění3-silné?

          Ad 2) Jsou ale dvě otázky:
          a) Co všechno je možné nazývat webovou aplikací:
          – jakoukoliv stránku pracující s daty uživatele,
          – jakýkoliv program stáhnutelný z webu (z hlediska principu je to stejné: buď se otevře nové okno prohlížeče se stránkou, která chce po uživateli nějaká data, nebo se stáhne .exe soubor, .jnlp soubor, … krerý si případně natáhne z netu nějaké další knihovny a spustí se jako lokální aplikace)?

          b) jaký je rozdíl v technologii webové prezentace a webové aplikace a jak mezi nimi bude prohlížeč rozlišovat, kdy se jedná o aplikaci a kdy o prezentaci?

          1. Nox

            Re: Soubory vybrané uživatelem

            1) v případě, že se změní pomocí CSS barevné schéma, tak už červená být lepší nemusí, a jsme v loji – budeme mít .red{color:green} :)

            2) Přišlo mi že za webovou aplikaci se považuje web, který pracuje s daty aplikace nebo obecně má alespoň rozumně rozvinutý backend, ale chápu že to není jednoznačně určeno. Uvedl jste „webová prezentace“, což mi prostě evokovalo web s minimem backendu a důrazem na frontend (firemní prezentace s nějakýma fotkama produktů, ceník a kontakt…tento styl), proto jsem tak reagoval.
            Nemyslel jsem, že by se to nějak rozlišovalo ze strany prohlížeče ale to, že pokud web provadí rozsáhlejší manipulace a výpočty atd., tak by nějaký důvod pro takovéto ukládání mít mohl

            1. Oxymoron

              Re: Soubory vybrané uživatelem

              1) to sice ano, na druhou stranu není problém zasáhnout do HTML.

              2) I tak, co mi má nějaký backend prohledávat můj disk?

  6. petr_p

    URI pro přístup z HTML

    Jako využití uvádíte:

    <blockquote>Soubory jsou používány přímo z lokální cache, přimým čtením nebo odkazováním pomocí lokálních URI na obrázky či videa, loadery WebGL obsahu, apod.</blockquote>

    Jak tedy vypadá URI, kterým se z HTML odkážu na soubor uložený v lokálním úložišti webového prohlížeče?

    1. Oxymoron

      Re: URI pro přístup z HTML

      Co třeba takto:

      file://C:/Document and Settings/Admi­nistrator/Docu­ments/Chrome/vi­rus/virus.exe

      ?

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3429