Firefox 10 je zunaj

Naj vstopi, da ne prezebe!

Ker določeni addoni delujejo potem problema sploh ni?

Kako natančno dejstvo, da moraš vsakih nekaj tednov popravljati addon zaradi spremenjenega APIja, izboljšuje dodatke?

In kot že rečeno, zakaj bi morali zaradi hitrejšega razvojnega cikla trpeti addoni? Je res tako težko ohraniti kompatibilnost s prejšnjimi verzijami APIja?

Nekaj let stare stvari so res outdated in jih ni nujno potrebno podpirati. Pa še za te bi bilo v nekaterih primerih smotrno narediti compatibility layer, ki bi omogočal delovanje na novejših verzijah. Pri nekaj mesecev starih verzijah pa ni razloga, da te ne bi bile podprte.

Za to, ker to spodbuja pisanje takšnih dodatkov, kjer tega ne rabiš več početi.

Trenutno je na verziji 0.7, API ki ga podpira je zelo omejen. V vsaki verziji malo dodajo, ampak to ni to. https://addons.mozilla.org/en-US/develo...
Ko rabis karkoli vec, pa si ze na teritoriju kjer API ni vec stabilen.

Poleg tega kdo pa zagotavlja da bo api stabilen? Mozilla? Se hecas... Mogoce kaksno leto, potem bojo pa odkril da je neka nova stvar malo boljsa in bojo spet vse na glavo postavl.

Mozilla se gre neki kao Firefox as a platform (se je sla?). Ampak kaj to pomaga, ce pa v vsaki verziji pokvarijo pol stvari. Recimo ce imas XPCom komponentno in jo hoces reusati v Mono-tu, sedaj to ne deluje vec, ker se XPCom integracija v Mono ni updatala ze kar nekaj casa (> 2 leti). Ne predstavljam si da bi v teh casih sel nekaj delati nekaj novega, kar bi bilo odvisno od Firefoxa.

Recimo, da bi vgradili PPAPI, kot varnostna nadgradnja staremu NPAPI, to kar so potem integriral samo v Chrome, pa jih ne zanima. NPAPI @ Wikipedia

Sej mogoce bo ta poteza cez par let videna kot dobra. Do takrat bojo pa pac zgubljali folk proti Chromeu. J**** ga. Life goes on. Folk bo rajsi delal na novih plaftormah in dodajal nove featurje, kakor na tem, da je potrebno vsake par tednov rewritati neke zadeve samo za to da se vedno neka stvar dela.

Sedaj integrirajo v 11 developer tools, ki bo nadomestil FireBug. Sicer izgleda super. Ne vem pa sicer zakaj mora to biti del Firefoxa in ne kot addon. A res to rabi vsak user? Verjetno bodo kmalu ugotovil da je Firefox tok bloated postal, da rabjo spet nek fork tipa Netscape -> Phonenix, kjer bo zadeva oklescena vsega nepotrebnega balasta.

Glede "omejenosti" API-ja v nekem trenutku in da to ni to. V bistvu to je to in ne vidim alternative. Dodatki in upravljanje s pomnilnikom sta dva glavna očitka FireFox zadnje čase, ki se najbolj izpostavljata ravno sedaj, ko se je prešlo na hitrejši razvojni cikel. Hitrejši razvojni cikel je prinesel izboljšave na obeh področjih.

Sem pogledal prvih 5 JetPack addonov (tam kjer sem nasel source v manj kot 10 sec) in opazil, da 5 od 5 uporablja vsaj del nestabilnega APIja. Vecina npr. uporablja preferences-service. Posledicno vsak izmed teh addonov bo lahko imel probleme ob novem FF updatu.

Podobna zgodba z libXul. Nekako se grejo nekaj v stilu Ubuntu Unity. Nekaj novega revolucionarnega na pol narejena in nestabilnega, medtem ko stara funkcionalnost ni vec podprta.

Sam sicer delam na C++ xpcom addonih ... jbg ... it currently sux to be Firefox addon developer ...

Ne gre se samo za združljivost z novejšimi različicami FF, katera se zagotovo z Jetpack dodatki bistveno izboljšuje, ampak Jetpack dodatki prinašajo še druge prednosti. Prva zadeva, ki jo opaziš je, da ne rabiš znova zagnati FF ob namestitvi. Z orodjem (Jetpack dodatek) about:nosy boš lahko imel natančen pregled, kako določen Jetpack dodatek "upravlja" s sistemskim pomnilnikom, "XUL dodatek" tega ne omogoča. "Problematičen zavihek" pri več dnevni seji boš lažje našel in se odločil, kaj boš z njim naredil... Ni potrebe torej po ponovnem zagonu spletnega brskalnika... In tako naprej seveda. Skratka ne bom jim očital, da gredo iz nečesa kar je nam je doslej dobro služilo in nam še služi in torej smatram za dobro na nekaj še boljšega in sodobnega in konkurenčnega.

Sec ... ce lahko uporabljam https://addons.mozilla.org/en-US/develo... sicer kot del nestandardnega apija, in lahko dela brez restarta browserja. Zakaj ze tega ni mogoce uporabiti brez Jetpacka in samo z obstojecim XPCom?

Traditional extensions include overlays, wherein the application can load up XUL from the extension's package and automatically apply it atop its own UI. While this makes creating extensions that add to the application's user interface relatively easy, it means that updating, installing, or disabling an extension requires an application restart.

Gecko 2.0 (Firefox 4 / Thunderbird 3.3 / SeaMonkey 2.1) introduces bootstrapped extensions. These are special extensions that, instead of using overlays to apply their user interface to the application, programmatically insert themselves into the application. This is done using a special script file that's included in the extension that contains functions the browser calls to command the extension to install, uninstall, start up, and shut down.

As an aside, extensions created using the Mozilla Labs Add-on Builder web site are bootstrapped; however, because all the bootstrapping code is generated for you, you don't really need to think about it.

Overlay vs. bootstrapped extensions

Firefoxovi dodatki so bili vedno dalec spredaj, ker si imel dostop do prakticno 3/4 FF APIja. In si lahko delas cuda dodatkov z njimi. Sedaj ta del ni vec stable in se tudi breaka iz verzije v verzijo. Developerjem se pa posledicno verjetno ne da vlagati cas v nekaj kompleksnejsega kar bo delovali samo 1 mesec. Ma skoda casa.

Jetpack je samo wrapper 10 zelo omejenih API classov okoli obstojece funkcionalnosti za katere so rekli, da ta pa bo sedaj mogoce stable nekaj casa. Skratka nic posebnega.

Ta dva dela je potrebno navesti skupaj da, da dobita skupaj smisel. Omejenost API-ja v nekem trenutku je odvisna predvsem od tega, kašen dodatek bi rad izdelal. Če presega zmožnosti, ki jih nudijo API-ji boš se morda ukvarjal več z združljivostjo z novejšimi različicami, ker boš uporabil tradicionalni ali mešan pristop, to je res, ampak zadeve so torej na koncu odvisne od primera do primera!

Mislis tak bolj priblizen. Overlayed based XUL ne zna trackat ...

To je res in za to sem višje napisal, da potrebuješ za prikaz obnašanja dodatka na tem področju s pomočjo orodja about:nosy Jetpack dodateke.

Poglej prve 3 strani tvojega linka dodatkov. 10 od njih ni vec kompatibilnih z FF 10. A ni kao Jetpack the shit in je vse v njemu stable in bo delovalo v novih verzijah?

Če boš ostal v okvirjih API-jev, ki so v danem trenutku na voljo bi verjel, da boš imel z združljivostjo z novejšimi različicami malo težav. Tudi dodatne izboljšave na tem področju so še možne:

4) Land APIs & Loader in Firefox

For quite a while, we have discussed landing the Add-on SDK APIs and Loader into Firefox itself. There are multiple benefits to this including either making repacks less frequent or altogether obsolete (in other words, ensuring add-ons using these high-level APIs would always remain compatible through different versions of Firefox), making add-ons built with the SDK much smaller, and possibly improving add-ons performance even more. In addition, this would give the SDK codebase even more legitimacy which could help us gain more developers using it to create add-ons.

Plans 2012

Treba je razmišljati tudi na sledeč način. Add-on SDK bo sčasoma zmogel več in potrebe po pisanju "XUL dodatkov" bo sčasoma manj. Zaenkrat pa lahko počneš oboje ali uporabljaš kombiniran pristop in za to se ne strinjam, da se razvijalcem tako hudo slabo godi. Bolj se gre za to, da so v takšnih temah bolj glasni uporabniki sami, ker ne vejo kaj bi raje uporabljali ali Chrome ali FireFox. Tam ko je izbira je ponavadi to normalno.