Ce journal semble oublier quelque chose: la raison du changement de l'API et de la déprécation de l'ancienne API n'est pas une raison politique, mais une raison technique.
En effet, l'API "historique" à base de XUL et XPCOM n'est pas compatible avec le multi-process au niveau des onglets, qui est une fonctionnalité que tout le monde demande... Sauf effectivement en employant un shim qui permet d'émuler un objet local en passant d'un processus à l'autre de façon synchrone. Quelqu'un se souvient-il de CORBA/Bonobo ?
Ils en profitent donc pour déprécier cette API et introduire quelque chose de plus moderne et de différent. Ils ont aussi développé le shim en question en prévenant bien que ça risquait de ramer, et prévoient de supprimer le shim dès que possible, quand les conditions suivantes seront réunies:
Les extensions populaires auront été réimplémentées afin de ne pas dépendre de l'ancienne API
Une solution viable sera disponible pour les extensions pour lesquelles l'API WebExtensions repompée de Chrome n'est pas suffisante.
Aussi, le calendrier mentionne bien qu'Electrolysis (càd le multi-process pour les tabs) ne sera pas encore activé par défaut dans la prochaine release mais sera disp en preview (càd avec les extensions XUL toutes lentes à cause du shim) pour les gens motivés.
Le seul bémol c'est qu'effectivement les extensions qui non pas été touchées depuis des lustres ou dont les auteurs ne se font pas entendre risquent de disparaître. Aussi, tout ceci (dont le multi-process) est déjà dispo dans Firefox Android, qui n'a jamais été en XUL.
Quant à la question de la signature obligatoire des extensions, c'est complètement orthogonal. Je peux comprendre le problème mais effectivement une option dans about:config serait probablement bienvenue.
# Raisons techniques
Posté par nud . En réponse au journal La fin du "permissive add-on model" chez Mozilla, ou comment flinguer une base d'extensions. Évalué à 10.
Ce journal semble oublier quelque chose: la raison du changement de l'API et de la déprécation de l'ancienne API n'est pas une raison politique, mais une raison technique.
En effet, l'API "historique" à base de XUL et XPCOM n'est pas compatible avec le multi-process au niveau des onglets, qui est une fonctionnalité que tout le monde demande... Sauf effectivement en employant un shim qui permet d'émuler un objet local en passant d'un processus à l'autre de façon synchrone. Quelqu'un se souvient-il de CORBA/Bonobo ?
Ils en profitent donc pour déprécier cette API et introduire quelque chose de plus moderne et de différent. Ils ont aussi développé le shim en question en prévenant bien que ça risquait de ramer, et prévoient de supprimer le shim dès que possible, quand les conditions suivantes seront réunies:
Aussi, le calendrier mentionne bien qu'Electrolysis (càd le multi-process pour les tabs) ne sera pas encore activé par défaut dans la prochaine release mais sera disp en preview (càd avec les extensions XUL toutes lentes à cause du shim) pour les gens motivés.
Le seul bémol c'est qu'effectivement les extensions qui non pas été touchées depuis des lustres ou dont les auteurs ne se font pas entendre risquent de disparaître. Aussi, tout ceci (dont le multi-process) est déjà dispo dans Firefox Android, qui n'a jamais été en XUL.
Quant à la question de la signature obligatoire des extensions, c'est complètement orthogonal. Je peux comprendre le problème mais effectivement une option dans about:config serait probablement bienvenue.