Asi jste zaznamenali, že Opera opouští vlastní vykreslovací jádro Presto a přechází na WebKit. Nevím, co bude s funkcí Opera Turbo, ale nejspíš by mohla v nějaké (byť technicky možná odlišné) podobě přežít. Co ale Opera Mini? Opera Software slíbila, že ji zachová. Což možná nebude tak jednoduché...
Jak funguje Opera Mini?
To, co si člověk stáhne do mobilu (klientská část Opery Mini), neumí ani HTML a CSS. To umí formát OBMP, který dostane ze serverů Opery. Nejde jen o nějakou obyčejnou kompresi typu GZIP. Server Opery patrně téměř kompletně vykreslí stránku a pošle ji v úsporném formátu klientovi. Ukázat si to můžeme malými experimenty:
- Zkuste otočit displej. Text se nijak nepřeskládá, vše zůstane tak, jak je. Text se přeskládá jen po reloadu stránky. Starší verze Opery Mini (zřejmě 4.*) se v tomto případě dokonce ptala, jestli uživatel chce stránku znovu načíst.
- Zkuste zkopírovat nějaký text na stránce. Zkopíruje se i s novými řádky a případnými přidanými mezerami. To jen podporuje variantu, kdy i lámání textu probíhá na serveru.
- Zkuste na nějaké stránce kliknout nějaké tlačítko, které provede nějakou akci offline. Například může jít o rozbalení/sbalení textu. (Dřív to šlo vidět dobře například na mobilní Wikipedii, dnes už ne.) Opera Mini to neprovede offline. Musí se zeptat serveru, co s tím. Javascriptová validace formulářů tak může docela obtěžovat.
Jistě by se našlo mnoho dalších příkladů. Formát OBML se nejspíš v jistém smysllu podobá PDF. Je to připraveno pro přesně dané rozměry stránky a nejde nějak snadno provést například text reflow. (Ano, u PDF to jde, ale je to spíš hack a jsou s tím spojeny jisté problémy, pokud se například používá dělení slov.)
A kde je problém?
Zkusme navrhnout, jak to implementovat. Mějme nějaké obecné jádro prohlížeče a implementujme nad ním prohlížeč podobný Opeře Mini. Co budeme potřebovat? Základ je jasný, klient pošle, řekněme, URL, rozlišení obrazovky a DPI, server to vykreslí a pošle zpět. Pro začátek třeba použijeme PNG, nebudeme řešit výběr textu, hledání, zoom ani datovou náročnost. Budeme asi muset sázet text do sloupců širokých nejvýše stejně jako obrazovka. To v případě WebKitu, který se používá v mnohých jiných mobilních prohlížečích, problém nebude. Budeme muset nějak udělat funkční formuláře, což vyřešíme posíláním pozic a identifikátorů jednotlivých elementů formuláře. Nejzajímavější ale může být implementace Javascriptu. Budeme muset vyřešit, která část stránky reaguje na kliknutí, udělat z ní odkaz, který se nějak speciálně zpracuje na serveru. Zároveň ale budeme chtít, aby se při kliknutí mimo klikatelné oblasti nemuselo nic vyměňovat se serverem. Toto už bude chtít celkem těsnou spolupráci s enginem.
Pokud se do toho Opera pustí touto cestou, nabízejí se navíc některé otázky. Udělá nějaký patch pro jednodušší integraci, který pošle vývojářům WebKitu? Kdo se o tyto patche bude starat? Bude se chtít vývojářům WebKitu?
Co s tím Opera udělá?
Je tu několik možností, jak se s tím Opera může vyrovnat.
Použít Presto pro Operu Mini?
Problém je v tom, že by museli Presto vyvíjet a záplatovat. Je otázka, jestli se to vyplatí. Nejspíš by to znamenalo jen vývoj v rozsahu oprav. Prvně jsem byl skeptický, ale postupně si kladu otázku, jestli by to nebylo u tohoto prohlížeče good enough.
Opustit stávající model renderování na serveru?
Pak by ale nejspíš nebyl rozdíl mezi Operou Mini a Operou Mobile (popř. Operou Ice). Pokud slibovali Operu Mini zachovat, pak asi nepůjdou touto cestou. To je dobrá zpráva pro uživatele J2ME verze, protože portovat WebKit pro J2ME by asi nikdo nechtěl. Když ne z jiných důvodů, tak kvůli nemožnosti spouštět přímo nativní kód. Kód v C++ by se špatně portoval.
Rozdělit WebKit na server a klienta?
Jak jsem psal, je to sice jedna z možností, ale jsou s tím spojeny různé výše uvedené komplikace. Možná by se změnil (zvětšil?) objem přenesených dat. Od verze 5 zřejmě v Opeře Mini funguje u interaktivních stránek někdy rozdílový update. (To je můj odhad podle měření objemu přenesených dat.) To by se mohlo změnit a třeba v první verzi by to nemuselo tak fungovat.
Co rozhodne
Vidím tu dvě reálné možnosti – adaptace WebKitu a udržování jádra Presto. Záleží na tom, jestli má jít o urdžení prohlížeče zhruba ve stávajícím stavu, nebo jestli Opera předpokládá další vývoj. Pokud předpokládá další vývoj, WebKit je asi jasná volba. Pokud ne, udržování jádra Presto (zejména opravy chyb) se může ukázat jako výhodnější varianta.
AKTUALIZOVÁNO: Opera kupuje Skyfire
Přidala se nová zpráva, kterou jsem si bohužel přečetl až po publikaci tohoto blogpostu. Totiž že Opera kupuje Skyfire. Trošku jsem zavzpomínal a pohledal a přinejmenším se dost nabízí, že Skyfire bude dost souviset s budoucí podobou Opery Mini. Dám sem citaci z článku z Wikipedie, které mluví za vše:
Je to otázka. Starší verze byla založena na jádru Gecko (stejně jako Firefox) a šlo o tenkého klienta stejně jako Opera Mini. Dnes staví na WebKitu, ale je mnohem blíže klasickým prohlížečům, protože na svém serveru zpracovává jen videa a podobný obsah. Může jít jen o komponentu do Opery Ice. Nebo se pro Operu Mini použije upravený kód ze Skyfire 1 a pro Operu Ice videa z novějších verzí Skyfire? Nevím, budoucnost je po tomto kroku ještě možná o něco nejasnější.
Žádné komentáře:
Okomentovat