Megjegyzés: A most következő postban a NEX, avagy egy böngészőgyártó-független csomagformátum kerül bemutatásra, amelyet az Opera fejlesztői a Chrome saját .crx formátuma alapján készítettek el. Céljuk, hogy egy nyílt, szabványokon alapuló add-on formátumot hozzanak létre. Innentől az ODIN blog fordítását olvashatjátok:

Amikor először bejelentettük, hogy Chromium-alapra állunk át, már rendelkeztünk egy részletes, mély áttekinthetőséggel az adoptálásra szánt Chromium rendszerrel kapcsolatban. Ezen fontos aspektusok egyike volt annak a folyamatnak az áttekintése, hogy a fejlesztők miként fejlesztik a Chromium alapú böngészőkhöz a kiegészítőket. Megnéztük a dokumentációt a böngésző kiegészítőkről és a csomagolt webalkalmazásokról.

A Chromium natívan támogatja a CRX formátumot a Google által lehetővé tett számos Application Programming Interface-szel (API). Mivel az Opera korábban csatlakozott a Google-höz, mint aktív Chromium projekt közreműködő megoldást akartunk találni arra, hogyan terjeszthetnénk ki a CRX funkciókészletét anélkül, hogy megbolygatnánk a már köré épült, meglehetősen méretes ökoszisztémát a rengeteg létező kiegészítővel.

A CRX formátum, mint egy egy-fejlesztő általi formátum (egészen mostanáig), nem foglalta magába a saját architektúrája kiterjeszthetőségét. Választás elé kerültünk: vagy kiterjesztjük a CRX formátum lehetőségeit, vagy készítünk valami újat, ami lehetővé tenné az Opera és más böngészőgyártók számára, hogy innoválják a saját Add-on API-jukat. Kutatásunk során arra jutottunk, hogy a hasonlóságok a különböző böngészők manifest formátumaiban (lényegében a bootstrap mechanizmus a kiegészítők betöltésére) messze túlhaladják a különbségeket. Miközben kerestünk a módját, hogy innováljunk és kiépítsük a saját kiegészítő környezetünket az Operánál, megláttuk a lehetőséget is, hogy ezzel párhuzamosan egy nagyobb és szélesebbkörű ötletet is beterjesszünk a nyílt webfejlesztői közösségek számára.

Ennek érdekében ma bemutatjuk a NEX formátumot. A NEX formátum kezdetben egyfajta szuper-készlete a CRX fejlesztői környezetnek melyet a Chromium fejlesztői már használnak. Az Opera mindig is erős elkötelezettje volt a nemzetközi, nyílt szabványoknak és ő maga is régóta aktív szerepet játszik a nyílt webes szabványok fejlesztésében. Ez nem változott azzal, hogy Chromiumra váltottunk. Céljaink egyike, hogy idővel a NEX is egy ilyen nyílt internetes szabvány legyen, melyet a W3C is támogat majd, kezdetben megosztott csomagok és manifest formátumokként kereszt-böngészős kiegészítőfejlesztéshez, megszüntetve a hallgatólagos függőségeket a CRX formátum irányába a NEX runtime segítségével, ahogy haladunk.

A nyílt webes szabványok használói képesek lesznek kiválasztani a böngészőjüket anélkül, hogy hozzá lennének láncolva egyetlen gyártóhoz vagy termékhez (akár a kiegészítőkön keresztül is). Egy rendszer, mely támogatja a felhasználók választási lehetőségét, könnyebbé teszi a kiegészítőfejlesztők életét és támogatja a megosztott innovációt mely egy egészséges, versenyképes web ökoszisztémát tesz lehetővé. A NEX egy ajánlás, amellyel a Chromium kiegészítőket - a komponenseket, melyek vitathatatlanul olyan fontos részévé váltak a mai webnek, mint maguk a weblapok tartalmai - egy olyan jövőkép kialakítása felé mozgathatjuk, ahol egy nyílt web magjának létrehozásában működünk közre és szilárdítjuk azt meg.

Mit kínál a NEX ma?

A mai Opera által implementált NEX formátum egy szuper-készlet a CRX futtatói környezet felett, habár elméletileg a CRX alap nem kötelező a NEX implementálásához. Az Opera 15-ben a NEX formátum exkluzív hozzáférést biztosít a Opera Extensions Speed Dial API-hoz. Más implementációkat is bárki szabadon hozzáadhat a saját API-jához.

Egy NEX fájl .nex fájlkiterjesztéssel rendelkezik és HTTP-n keresztül érkezik az application/x-navigator-extension MIME type-pal. A fájltípus és a tartalomtípus megváltoztatásával különbséget kívánunk tenni a kereskedelmi fejlesztések között és azok között, amelyek a közvetett kompatibilitás miatt szükségesek más futtatókörnyezetekkel. Az ezzel kapcsolatos témákról a továbbiakban itt olvashattok.

Az Opera a továbbiakban is implementálni fogja a létező CRX formátumot különállóan az Opera 15+ verziókban, így a fejlesztők akik jelenleg a Chromium API-t ismerik, továbbra is folytathatják a fejlesztést és tölthetik fel a CRX-alapú kiegészítőiket az Opera Add-ons katalógusba ugyanúgy, ahogy a Chrome Web Store-ba.

Hogyan fog a NEX fejlődni?

A NEX fejlesztésének kezdeti célpontja a csomagoló és manifest formátumok normalizálása körül fog zajlani, melyek a Chromium és más böngészőfejlesztők folyamatban lévő projektjei — a munkát jelenleg a Mozilla koordinálja a W3C-n keresztül.

A közeljövőben azt szeretnénk, hogy a NEX olyan rugalmas legyen, akárcsak maga a web és egyben egy hely a web legjobb praktikáinak használatára és népszerűsítésére. Konkrétan azt szeretnénk, hogy a böngészőkiegészítő fejlesztők a legjobb gyakorlatot tegyék magukévá, avagy feature detection és kereszt-böngészős környezet a kiegészítők kompatibilitása érdekében. Adott egy szabványos kiegészítő-csomag, mely végrehajtható különböző futtatókörnyezetek alatt - hogy egy hidat nyújtson a funkcionálisan egyenértékű, ám programozásilag eltérő API-k között - ami egy hatalmas lehetőség a webfejlesztők számára. Azt akarjuk, hogy ennek segítségével a fejlesztők egyesített böngészőbővítmény kódot tudjanak írni a különböző API könyvtárakhoz és képesek legyenek futtatni ugyanezen fájlokat különböző futási környezetekben.

Hosszabb távon az Opera azt szeretné, hogy a NEX ösztönözze a valódi és jeletőségteljes eszmecserét a szabványosított API-kkal kapcsolatban (esetleg kezdetben a már meglévő kereskedelmi, de-facto szabványokkal együtt). Amennyiben a böngészőgyártók magukévá teszik ezt az általános csomagolási és manifest formátumot, akkor ezzel egy új, sokkal magasabb szintre lépnének a rendszerszintű alkalmazás API-k terén, továbbá nagyban megkönnyítenék a kiegészítő fejlesztők munkáját. A tény, hogy a gyártók nem osztoznak egyetlen közös környezeten eléggé megnehezíti ezen törekvés véghezvitelét. A NEX-szel reméljük, beindíthatjuk ezt a törekvést az API-k szabványosítása irányába, hogy végül egy egyesített böngésző kiegészítő fejlesztői környezetet hozhassunk létre.

Az Opera a közeljövőben továbbra is folytatja a CRX futtatókörnyezet követését mind a csomagolás, mind a manifest fájlok, mint a Chromium API által nyújtott lehetőségek terén. Idővel azonban az a tervünk, hogy a NEX-et a nyílt, W3C szabványok irányába toljuk, miközben fokozatosan eltávolításra kerülnek a CRX rendszer kereskedelmi részei annak érdekében, hogy az NEX annyira szabványos legyen, amennyire csak lehet.

Hogyan vehetek részt a folyamatban?

Számos dolog van, amit megtehetsz annak érdekében, hogy segíts sikerre vinni az elképzeléseinket egy nyílt, megosztott ökoszisztéma irányába a jövőben.

Annak érdekében, hogy legyen egy megosztott csomagoló és manifest formátumunk, az Opera nagy erőkkel vesz részt a szabványosítási munkálatokban a W3C bizottságban és másokat is bíztatunk a részvételre és arra, hogy segítsenek nekünk céljaink véghezvitelében.

A NEX hosszú távú céljai között szerepel, hogy végig kell gondolnunk mely dolgok legyenek a megosztott kiegészítő API-kban és hogyan nézzenek ki a könyvtárak. Van egy csoport a W3C-nél akik kifejezetten ezt a célt tartják szem előtt. Eközben népszerűsítenünk kell a feature-detection-t annak érdekében, hogy a lehető legzökkenőmentesebben történjen meg a böngészők közötti átmenet. Tudunk ma írni olyan JavaScript könyvtárakat, amelyek segítik a kiegészítők böngészők közötti átjárhatóságát? Hogyan tudnánk enyhíteni a fejlesztőket érintő kihívásokat a böngészők közötti kiegészítők írásában? Ezek mind magas prioritású feladatok egy erős, kiegészítő-fejlesztési platform érdekében, és szeretnénk minél több különböző érdekeltségű felet találni, hogy közösen találjuk ki a legjobb megoldásokat.

Következtetés

Az Opera 15 aktuális NEX implementációja tükrözi az első lépést a nyílt, szabvány-alapú fejlesztői környezet irányába. Mindkét tényező elengedhetetlen az alapvető stabilitáshoz és ahhoz, hogy a jövőben egy valóban univerzális alkalmazás platformot kínáljunk. Mint közösség és mint részvevők ebben a folyamatban, rengeteg szabványosítással kapcsolatos munkánk lesz, mellyel megalapozhatunk egy szebb jövőt.

Amennyiben még többet szeretnél tudni a NEX-ről, esetleg írni is szeretnél NEX kiegészítőket, bátran fordulj a NEX documentációnkhoz további információkért.

(forrás)

A következő postban már jó ideje gyűjtögetem azon oldalak címeit, ahol nem csak száraz szintetikus tesztek vannak, hanem valódi aktív tartalom. Ezeken az oldalakon ki lehet próbálni a HTML5, JavaScript és Canvas sokrétűségét.

Az egyik legismertebb ilyen oldal, amely Operával is működik, ellentétben az Apple hasonló oldalával a Chrome Experiments oldala.

Van még néhány hasonló gyűjtő oldal, az egyik a Canvas Demos ahol mindenféle Canvasban és JavaScriptben írt játékok vannak a memóriától a Super Mario-ig és a HTML5Games.com.

Ezen az oldalon például egy 3D-s, 360 fokban forgatható mobiltelefon van. Természetesen HTML-ben, ehhez sem szükséges semmilyen beépülő.

Itt a renderelési sebességet lehet tesztelni.

Itt egy Tetris játék van HTML alapokon, de régi, klasszikus FPS játékaink sem maradhattak ki a sorból. Bár ezek az FPS-ek még nem teljes játékok, de készült már Wolfenstein és Doom is JavaScript+Canvas-ban.

A következő oldal már kicsit jövőbe mutató, ahol valós időben konvertálhatjuk a HTML5 videót ASCII kóddá.

Amint a fenti példák is mutatják, ötletben nincs hiány, már csak az erőforrásigényt kell még a jelenleginél is lejjebb dolgozni és végre búcsút mondhatunk a zárt és harmadik féltől származó megoldásoknak és az ehhez szorosan kapcsolódó biztonsági réseknek, instabilitásnak és memóriaszivárgásoknak.

Ezennel a Google hivatalosan is beverte az utolsó szöget a Flash, de alighanem az MPEG-LA koporsóján is.

A WebM Project keretében most már a Google, Mozilla, Opera és több, mint 40 tartalomszolgáltató, szoftver és hardvergyártó teríti együttes erővel a jelenleg létező legjobb, immáron nyílt videóformátumot.

Mostantól a YouTube HTML5 része is működni fog Operával.

Valamint pár perc múlva érkezik az új előzetes, ami Haavard szerint valami meglepetést tartogat.

Az utóbbi 1-2 évben - legújabban éppen az Opera 10.5 kapcsán - ha szóba került a JavaScript, akkor túlnyomórészt a milliszekundumok játsszák a főszerepet, azaz a különféle sebességtesztek. Tulajdonképpen mindenki alapnak veszi, hogy JavaScript terén csak ez lehet a különbség a böngészők között.

Pedig a nyelv elég összetett ahhoz. hogy az egyes böngészők a szabványt ne mindenhol kövessék megfelelőképpen. Sőt, ahogy a Chromium blog bejegyzése fogalmaz: a net (a "való világ") akár meg is követelheti a szabvány megkerülését.

Persze elsősorban nem ez a követendő példa. A nevezett cikkben szereplő Sputnik tesztnek például éppen az a célja, hogy a szabványkövetést ellenőrizze különböző tesztesetek futtatásával. Jelenleg az ECMA-262 3. kiadása alapján ellenőrzi több, mint 5000 rövid teszt futtatásával, de várható a mostanában bemutatkozó ECMAScript 5 folyamatos beépítése is.

Bár a kezdeményezés tavaly júniusra datálódik, mostanra készült el az a tesztsorozat, ami képes az összes tesztet gyors egymásutánban lefuttatni a böngészőkben. Persze a lap készítői mindjárt meg is ragadták az alkalmat, hogy leteszteljék a legnépszerűbb böngészőket, íme az eredmények:

Némi magyarázat persze szükséges. Minél több tesztet teljesít sikerrel egy böngésző, annál közelebb van a középponthoz. Az Opera a 10.5 a jelenleg elérhető 5245 tesztből 5167-et sikerrel teljesít, azaz mindössze 78 hiba fűződik a nevéhez. Ezzel szemben a Safari 159, a Chrome 218 a Firefox 256, az Internet Explorer pedig 463 hibát vét. Ezek alapján tehát az Opera teljesít legjobban ebben a kimerítő tesztben!

Az sem mindegy, hogy hol helyezkednek el a körön belül: minél közelebb van egymáshoz két böngésző, annál több a "közös hiba". Látható, hogy az Explorer számos hibája egyben meglehetősen egyedi is. Ezzel szemben a többiek nagyjából együtt vannak, megtartva persze a tisztes távolságot.

A tesztoldalon bárki letesztelheti a saját böngészőjét. Arra azért figyeljünk, hogy meglehetősen gépigényes, főleg régebbi böngészőt és lassabb gépet használók számítsanak lassulásokra, esetleg a teszt megszakadására. Egy leállítás és újraindítás segíthet az ügyön.

Aki esetleg nem ismerné: a Presto az Opera renderelő motorjának a neve. Az Opera 7-ben mutatkozott be először és azóta számos fejlesztésen esett át. Jelenleg az Opera 10-es verziójában a Presto 2.2.15 található meg, de talán már nem kell sokat várnunk a következő változatra. Elvileg a fejlesztők már végeztek a 2.3-al, és jelenleg a 2.4-en dolgoznak. Sajnos megjelenési időpontokról nincs információnk, sem arról, hogy a következő Operában melyik verzió lesz benne.

Mindenesetre a háttérben folyó munka bizonyítékaként az Opera dokumentációk között nemrég feltűnt a Presto 2.3 által támogatott szabványok és ajánlások listája, meglehetősen részletezően bemutatva, hogy minimálisan mit várhatunk a következő Operától. A dokumentumban számos link található, ahol részletesebb információt kaphatunk az adott szabványról, vagy az egyes attribútumok és metódusok támogatottságáról.

Úgy vélem, ezek az információk inkább a webfejlesztők számára érdekesek, de közvetve az átlagfelhasználókat is érintik, hiszen mindenkinek az érdeke, hogy a web minden eddiginél érdekesebb, szebb és rugalmasabb legyen. Ezért érdemes figyelmet fordítanunk a lényegi újdonságokra, főleg amik a böngészőháború közepette szélesebb nyilvánosságot kaptak. Mivel jómagam nem vagyok webfejlesztő (szerencsére), ezért igyekszem csak az alapokra szorítkozni, a további lényegi észrevételeket viszont most is szívesen veszem a fórumban.

Főbb támogatott szabványok és API-k a Presto 2.3-ban:

• fejlettebb canvas
• részleges video és audio
• széleskörű HTML
• HTML5 Forms
• OpenGL API
• Direct3D API
• CSS3 Transitions és border-radius

A fentieken túl persze számos javítás, változtatás, apróbb bővítés kapott benne helyet, akit részleteiben érdekel, az olvassa el a teljes listát. Ezek tehát azok a funkciók, amik a Presto 2.3-ban már megvalósultak, az új Opera tehát ennél csak jobb lehet, legalábbis reménykedek benne.