Mais ça poserait les mêmes problèmes de portabilité et de sécurité que native client (NaCl), non ?
Mozilla a strictement refusé NaCl parce que le code généré n'est pas portable (puisque c'est du code machine). Niveau sécurité, un gros effort a été fournit par Google pour empêcher ce code machine de sortir du cadre du navigateur.
Permettre l'accès à une API externe, c'est cumuler les deux défauts : l'API n'est disponible que sur certaines machines, et la sécurité n'est pas garantie comme dans native client. XUL étant fait pour écrire des applications bureau, c'était pertinent, mais l'objectif de Firefox OS étant aussi de créer des APIs javascript portables (et à terme standardisées), ce serait étonnant qu'ils acceptent ce genre de pont vers le système…
Après, s'ils optimisent suffisamment emscripten et asm.js, on peut supposer que sur certaines machines, l'aspect bas niveau ne soit plus un problème. Dans ce cas, une solution serait d'avoir une API qui puisse faire les deux : utiliser le code machine dans un cas, ou utiliser la bibliothèque compilée avec emscripten dans l'autre, sans modification du côté du code de l'application…
[^] # Re: Firefox OS
Posté par daeldir . En réponse au journal FluidSynth + Firefox = Music Toys. Évalué à 1.
Mais ça poserait les mêmes problèmes de portabilité et de sécurité que native client (NaCl), non ?
Mozilla a strictement refusé NaCl parce que le code généré n'est pas portable (puisque c'est du code machine). Niveau sécurité, un gros effort a été fournit par Google pour empêcher ce code machine de sortir du cadre du navigateur.
Permettre l'accès à une API externe, c'est cumuler les deux défauts : l'API n'est disponible que sur certaines machines, et la sécurité n'est pas garantie comme dans native client. XUL étant fait pour écrire des applications bureau, c'était pertinent, mais l'objectif de Firefox OS étant aussi de créer des APIs javascript portables (et à terme standardisées), ce serait étonnant qu'ils acceptent ce genre de pont vers le système…
Après, s'ils optimisent suffisamment emscripten et asm.js, on peut supposer que sur certaines machines, l'aspect bas niveau ne soit plus un problème. Dans ce cas, une solution serait d'avoir une API qui puisse faire les deux : utiliser le code machine dans un cas, ou utiliser la bibliothèque compilée avec emscripten dans l'autre, sans modification du côté du code de l'application…