Magyar Opera

A NEX bemutatása - szabványos kiegészítők

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 bejegyzés trackback címe:

https://magyaropera.blog.hu/api/trackback/id/tr985436260

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Krissz5435 2013.07.31. 22:44:28

Szóval ha jól értem, akkor a nex által írt kiegészítő több böngészőben is telepíthető lenne? Magyarul, ha a speed dialjukból csinálnának egy kiegészítőt, akkor ugyanazt kapnánk chrome és firefox alatt is, mint opera alatt?

penge™ · http://www.thevenusproject.com/ 2013.07.31. 23:16:28

@Krissz5435: A core API közös csak. Arra mindenki azt épít, amit akar. Szóval ha más böngészőben nincs Speed Dial, akkor hiába hivatkozik a Speed Dial API-ra, nem fog működni. Ettől függetlenül telepíthető lesz.

Értsd: A fejlesztő ilyen esetben létrehoz egy opciót, hogy a kiegészítő beállításaiban ki lehessen választani, hogy hol jelenjen meg a szükséges információ (pl. időjárás vagy tőzsdei adatok):
Button (everywhere)
Statusbar (only Firefox)
Speed Dial (only Opera)

De ezek extrém esetek. Itt az a lényeg, hogy az alap kiegészítők többsége általában vagy button formájában dolgozik buborékként, vagy a weboldalakba injektál kódot. Ez pedig cross-browser lehetne.

Értsd: pl. most nem kéne kínlódni, hogy nincs HotkeyBB, sem Website Monitor, sem HyperTranslate egyikre sem, hanem lehetne használni mindegyiket mindegyik böngészőben, mert ezek működéséhez olyasmi szükséges csak, ami minden böngészőben közös, csak másképp van implementálva.

De egy csomó népszerű addont is említhetnék, mint Adblock, Ghostery, LastPass, Xmarks, Web of Trust és társai.

De még egy egyszerűbb, böngészőspecifikus kiegészítőt, ami pl. a böngészőkben lévő belső lapokra hivatkozik (Opera Internal Pages vagy a Chrome-os, illetve Firefoxos megfelelője) is egyszerűbb lenne megírni. Egyrészt szükséges esetben szét lehetne csapni if-else struktúrával, másrészt még erre sem lenne szükség, tekintve, hogy az:
"about:" az about oldalra visz mindhárom böngészőben.
Az about:plugins a beépülők oldalára visz mindhárom böngészőben.
Az about:config szintén működik a régi Operában és a Firefoxban is. Chrome-ban és az új Operában az about:flags visz a chrome:flags és opera:flags oldalakra, és így tovább.

Krissz5435 2013.07.31. 23:21:16

@penge™:
Azért így sem lenne rossz. Ha lenne egy jó kiegészítő, akkor a többi böngészőben is szépen menne, feltéve, hogy nem kell külön böngészőspecifikus api hozzá.

Tebi 2013.08.01. 11:50:47

Ez tetszik! Csak nem haltak ki az ötletek, meg a régi alapelvek teljesen az operánál, ha ezt sikerül összehozni mindenki jól járna, persze nem hiába a cécó, egyértelmű hozadéka lenne, hogy egy kisebb népszerűségű böngésző is megkapná a legtöbb kiegészítőt ezáltal, bár ezt ők már jórészt áthidalták azzal, hogy chromiumra alapoznak, mégse csak ülnek a seggükön. Kíváncsian várom mi lesz belőle, és mivel rukkolnak még ki.

Nekomajin · http://nekomajin.wordpress.com 2013.08.01. 16:25:30

Így mondjuk az is rögtön érthetővé vált, hogy miért nem implementálták rögtön az összes Chrome-os API-t. Látszik, hogy van itt munka a háttérben. És ha végre könyvjelzők is lennének, sok ember szíve megenyhülne. :D

MosoMasa 2013.08.02. 18:01:23

@Nekomajin: Hát a könyvjelző az nagyon kéne. A többi engem olyan nagyon nem zavar, vagyis ráérnek.
Ja, meg hát a yt ... továbbra is problematikás.

ZeGa 2013.08.06. 09:22:29

Eddig nekem nem tűnt fel, de most néztem, hogy a jelszókezelőben ilyen egyszerűen meg lehet nézni a jelszavakat? Ez nem aggasztó egy picit? Valaki odaül a géphez és pár másodperc alatt kiírja a felhasználó mentett jelszavait.

Tebi 2013.08.06. 12:32:28

@ZeGa: Ha valaki azt akarja egy webbrowserpassview-vel amit még telepíteni se kell tényleg pár másodperc alatt nem csak hogy megnéz egy kettőt, de pár kattintással egy fájlba ki is menti az összes jelszavad, de amúgy jogos, tényleg lehetne hozzá mondjuk egy mesterjelszó vagy vmi, amivel levédheted, legalább magát a jelszókezelőt. Vagy ha már meg lehet nézni átírni miért nem lehet? Nekem párat felhasználó név nélkül hozott át a 12-ből, azt egyszerűbb lett volna szerkeszteni pl mint belépni és újgy lementeni, de ha jól tudom ezen a területen még pont dolgoznak.

RaidX 2013.08.06. 15:07:41

@Tebi: Arról nem is beszélve, hogy a lastpass-t favorizálja jelenleg az opera.
Amúgy a 12.xx alól is pillanatok alatt ki lehet nyerni a jelszavakat az "OperaPasswordDecryptor" progival. Van portable változata is. Ha nem standard telapítésű az Oper akkor meg kell e proginak mutatni a wand.dat fájlt és már mentheted is ki a jelszavak.

Erdeg Fattya 2013.08.08. 14:54:36

Kint a 17 Dev.Előzetes.
my.opera.com/desktopteam/blog/2013/08/08/opera-17-first-developer-stream-preview
Nálam mégjobb min a 15 stabil sebességben.
Persze ez még gazdagon összefossa magát főleg témák cserélgetésénél.
süti beállítások módosítása