Adobe et Mozilla vont donc travailler ensemble sur cette machine virtuelle, afin de profiter chacun d'une implémentation complète et performante des futures versions d'Ecmascript (en particulier Ecmascript 2 édition 4), ce qui est l'objectif du projet Tamarin de Mozilla.
Concrètement, le projet Tamarin permettra d'avoir des performances accrues sur l'exécution des scripts javascript dans les pages web, dans les extensions, dans les applications XUL, et donc dans le futur Firefox 3. Pour rappel, ActionScript est l'implémentation dans Flash 9, du standard Ecmascript. Il s'agit d'un langage de script standardisé par l'organisation internationale ECMA sur lequel sont basés le javascript de Mozilla, et le javascript (plus ou moins complètement) des autres navigateurs. Brendan Heich, "directeur de la technologie" et membre du "board" à la fondation Mozilla, est l'inventeur de Ecmascript/Javascript.
Actuellement, dans Mozilla, le javascript est interprété à la volée. Ce qui veut dire qu'à chaque fois qu'une fonction est appelée, à chaque fois il y a un processus d'interprétation, ce qui est assez coûteux en terme de performance (et la plupart des implémentations de javascript dans les autres navigateurs fonctionnent sur ce principe).
À l'inverse, la machine virtuelle d'Adobe fonctionne sur le même principe que les autres machines virtuelles (Java, Mono...) : elle permet de générer du bytecode à partir des sources javascript, et d'exécuter ensuite ce bytecode autant de fois que nécessaire, opération qui est moins coûteuse que l'interprétation à la volée. Elle permet aussi de faire du JIT (Just In Time) et donc de transformer le bytecode directement en instructions machine.
Aller plus loin
- Communiqué de presse (3 clics)
- Article sur sur xulfr.org (2 clics)
- L'annonce de Franck Heicker, Directeur Exécutif de la fondation Mozilla (3 clics)
- Projet Tamarin (3 clics)
# Et shockwave ?
Posté par yoho (site web personnel) . Évalué à 4.
[^] # Re: Et shockwave ?
Posté par JoeBar . Évalué à 10.
Oui, par la Chine.
[^] # Re: Et shockwave ?
Posté par Pierre Jarillon (site web personnel) . Évalué à -2.
[^] # Re: Et shockwave ?
Posté par omnikron . Évalué à -5.
# Rectificatif
Posté par Jean-Philippe (site web personnel) . Évalué à 9.
En tout cas c'est une bonne nouvelle pour la standardisation du langage Javascript et j'espère que le projet sera repris par les autres navigateurs libre comme konqueror.
Et, encore une note positive (j'ai perdu la source par contre), cette machine virtuelle est disponible pour les 64 bits ce qui voudrait donc dire qu'il y à de grandes chances de voir un flash 9 pour 64 bits
[^] # Re: Rectificatif
Posté par Jean-Philippe (site web personnel) . Évalué à 8.
Malgré le fait que Adobe ait libéré (http://blogs.adobe.com/penguin.swf/2006/11/open_source_actio(...) 135000 lignes de code, ils n'ont pas libéré leur soft java qui génère le bytecode pour actionscript (pas bytecode pour javascript 2, ni de JIT pour mozilla donc il me semble)
[^] # Re: Rectificatif
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
Je pige pas par contre ton histoire de soft Java ... Y a pas de java dans flash...
Et puis je ne vois pas l'interet d'une machine virtuelle si elle ne génère pas du bytecode....
[^] # Re: Rectificatif
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
Et il n'y aurait pas alors de parser javascript/générateur de bytecode dans ce qu'ils ont filé ?
C'est probable en effet (je suis pas encore aller tout voir...)
Cependant, spidermonkey sait parser du JS, et comme on a les sources de la machine virtuel, c'est assez "relativement" "aisé" alors de générer du byte code :
parser (spidermonkey) -> génération de bytecode (générateur à développer ?) -> execution du byte code (la machine virtuelle d'adobe)
[^] # Re: Rectificatif
Posté par Mjules (site web personnel) . Évalué à 3.
http://www.framasoft.net/article3536.html
http://www.mtasc.org/
[^] # Re: Rectificatif
Posté par Antoine . Évalué à 6.
http://haxe.org/
[^] # Re: Rectificatif
Posté par Jean-Philippe (site web personnel) . Évalué à 5.
http://www.kaourantin.net/2006/11/spidermonkeys-relative-tam(...)
Ce monsieur est ingénieur chez Adobe et travaille sur le flash player, il me semble qu'il travaille main dans la main avec le développeur principal de flash pour linux.
Il y aura donc un JIT pour mozilla.
Par contre :
Il y a bien du code java pour générer du bytecode ecmascript, code utilisé dans la plate-forme flex (et sûrement dans Flash pour créer les .swf).
D'après ce que j'ai compris ils ont libéré du code qu'ils ont écrit il y a peu pour leur garbage collector (ramasse-miettes), ce qui amène un gros gain de performances rien que pour leur player. On peut donc imaginer la même chose pour mozilla, ce qui ne présage que de bonnes choses :-)
[^] # Re: Rectificatif
Posté par Olivier Faurax (site web personnel) . Évalué à 3.
ECMAScript --> Bytecode pour Tamarin (compilé) --> execution sur le processeur
Pour l'instant, sur Firefox, on a :
ECMAScript --> interprétation par SpiderMonkey --> exécution
La compilation est presque tout le temps beaucoup plus efficace que l'interprétation.
Avec Tamarin, les 2 fonctions principales qui accélèrent sont le JIT (compilatio à la volée) et le ramasse-miette (gestion/récupération de la mémoire à la volée).
Ce qui n'a pa été libéré, c'est la partie :
ECMAScript --> Bytecode pour Tamarin
Donc, le futur boulot, c'est de mettre Tamarin dans SpiderMonkey pour que SpiderMonkey compile pour Tamarin.
En gros, c'est :
ECMAScript --> SpiderMonkey --> Bytecode Tamarin --> exécution
Pour les puristes (ceux qui aiment la purée ;) ), la page Tamarin indique qu'en fait Tamarin sera DANS SpiderMonkey, c'est à dire que c'est le même bidule qui interprète/compile/exécute l'ECMAScript.
Et au final, ils sont pas fous chez Adobe, ils gardent leur avantage concurrentiel, c'est-à-dire l'outil qui génère le code Tamarin depuis des bibliothèques (optimisées) de gestion audio/video.
[^] # Re: Rectificatif
Posté par Antoine . Évalué à 5.
Pardon ? Tu ne crois pas que le moteur de rendu du lecteur Flash est écrit en ActionScript quand même ?
[^] # Re: Rectificatif
Posté par Olivier Faurax (site web personnel) . Évalué à 1.
Je connais pas assez bien Flash.
Mais alors là, je comprends pas pourquoi ils ont par libéré leur compilateur d'ECMAScript vers Tamarin.
Ça leur permettait d'ouvrir complètement la chaîne de compilation et de proposer une valeur ajoutée en fournissant des bibliothèques audio/video/pdf/etc.
Je sais, on s'en fout, on a SpiderMonkey, mais bon...
[^] # Re: Rectificatif
Posté par herodiade . Évalué à 3.
Timic Uro (le chef de proj. Flash chez Adobe) l'explique : parce qu'il n'est de toutes façons pas utilisable pour FF :
* Il est en java (donc déjà, ça le fait pas)
* Son architecture ne permet pas de gérer l'instruction eval() (donc impossible de le rendre totalement compatible avec le standard ECMAScript 4).
Si je comprend bien le but est maintenant d'écrire le compilateur Ecmascript ... en Ecmascript !
Ref. http://www.kaourantin.net/2006/11/spidermonkeys-relative-tam(...)
[^] # ils n'ont pas libéré ...
Posté par salvaire . Évalué à -2.
[^] # Re: ils n'ont pas libéré ...
Posté par Jean-Philippe (site web personnel) . Évalué à 0.
[^] # Re: ils n'ont pas libéré ...
Posté par ☂ Tramo . Évalué à 5.
Euh non c'est l'inverse, ECMAScript est le descendant normalisé du JavaScript créé par Netscape et de JScript, sa variante microsoftienne.
[^] # Autre rectificatif
Posté par alung . Évalué à 2.
Cf http://www.mozilla.org/projects/tamarin/faq.html#when
et http://www.hecker.org/mozilla/adobe-mozilla-and-tamarin
# Penguin.SWF
Posté par faden . Évalué à 3.
http://blogs.adobe.com/penguin.swf/
J'ai installé la béta 9 du flash player sur mon linux et ça fonctionne déjà incroyablement mieux que l'ancien flash player 7, en terme de performance et de fonctionnalitées.
[^] # Re: Penguin.SWF
Posté par Pascal . Évalué à 0.
http://www.gnu.org/software/gnash/
[^] # Re: Penguin.SWF
Posté par gentildemon . Évalué à 6.
A priori, Adobe contrôlant la techno, le but de gnash est d'arriver au même niveau de fonctionnalités que le plugin proprio. Plus le plugin proprio est avancé, plus il y a de boulot pour gnash...
J'ai donc du mal à voir comment on peut s'intéresser à gnash et dire qu'on se moque du plugin proprio flash.
[^] # Re: Penguin.SWF
Posté par TeraHertZ . Évalué à 9.
On en a pas rien à foutre de cette techno, mais du greffon propriétaire et limitatif! d'où l'implémentation libre d'une alternative.
Maintenant question: est-ce que ça va retarder/faire perdre l'intérêt du SVG?
Il est clair que l'hégémonie dont jouie Flash™ va être difficile à "déstabiliser".
Je persiste à dire que ce qui fait le succès de Flash™ c'est sa platforme de developement, et non le format en soit.
Bon en effet, il est vrai que les performances sans au rendez-vous comparées à du SVG animé, à ce sujet, il se pourrait bien que la réponse à ma question influe sur les performances des futures "application SVG.
enfin..
[^] # Re: Penguin.SWF
Posté par Larry Cow . Évalué à 6.
A contrario, Gnash n'est pas limitatif du tout. Ce qu'on lit, de nos jours, quand même...
Je préfère également une solution libre à une pas libre, mais de là à prétendre qu'une copie incomplète (mais libre) d'un truc propriétaire est _techniquement_ plus accompli que l'original, faut peut-être pas mousser pépé.
[^] # Re: Penguin.SWF
Posté par TeraHertZ . Évalué à 7.
En outre, le côté limitatif ce n'est pas trop la capacité qu'a le logiciel à traiter ce genre d'infos mais plutôt le déploiement de celui-ci.
Par limitatif je voulais donc parler de: du fiat de sa nature proprio, ce qui déjà pue©, cela induit une disponibilité réduite selon O.S. et architecture. Le comble pour un techno qui se veut interopérable ou du moin utilise un media intéropérable, non?
En clair, tu me fais dire ce que je n'ai pas dit.
[^] # Re: Penguin.SWF
Posté par pasBill pasGates . Évalué à -2.
_TU_ n'en as rien a foutre.
[^] # Re: Penguin.SWF
Posté par atlexx . Évalué à 4.
"on",e en français est indeterminé . "on" ne signifie pas "nous" . _TU_ n'as donc pas de raisons de te sentir concerné. Peut être l'auteur de ce commentaire, que je n'approuve pas, connait d'autres personnes inclues dans "on".
</complètement HS>
[^] # Re: Penguin.SWF
Posté par Narishma Jahar . Évalué à 2.
[^] # Re: Penguin.SWF
Posté par Frédéric COIFFIER . Évalué à 3.
Sans faire de ma configuration une référence, je n'ai eu aucun plantage Flash 9 depuis que je l'ai installé... (et pourtant, j'utilise Konqueror sous Gentoo)
[^] # Re: Penguin.SWF
Posté par B16F4RV4RD1N . Évalué à 3.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Penguin.SWF
Posté par Mathieu Pillard (site web personnel) . Évalué à 5.
Par ailleurs, ils disent qu'il ya des problemes connus avec l'audio:
http://blogs.adobe.com/penguin.swf/2006/11/chart_toppers.htm(...)
Mais pas de son du tout, ca ressemble plus à un probleme de dmix non présent, et la version 7 devait utiliser oss ou esd...
Sinon, moi j'attends toujours un support pulseaudio mais je dois etre le seul :-)
[^] # Re: Penguin.SWF
Posté par olebrun . Évalué à 1.
[^] # Re: Penguin.SWF
Posté par ploum (site web personnel, Mastodon) . Évalué à 6.
Je vais tenter de reproduire le bug après avoir recompilé la version de debug et faire tourner le tout dans gdb. Je pourrais poster une trace sur le bugzilla.
Ah tiens non, c'est proprio.
Tant pis.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Penguin.SWF
Posté par Mathieu Pillard (site web personnel) . Évalué à 3.
http://www.adobe.com/cfusion/mmform/index.cfm?name=fp_beta_f(...)
# Une pièce du puzzle
Posté par Ontologia (site web personnel) . Évalué à 10.
Apollo est une plateforme constituant un environnement d'exécution basé sur les technologies Flex/Flash, Html/Ajax ainsi qu'un moteur PDF.
Des fonctionnalités permettant de gérer le mode déconnecté sont inclus dans la plateforme.
Avec cette technologie, plus besoin de navigateur, en effet, ils utilisent carrément WebKit, l'évolution Made by Apple de KHTML avec un moteur JavaScript.
Avec tout cela, on aura des applications Ajax/Flex/PDF sur le poste de travail qu'il sera difficile de différencier d'une application standard. Le socle pèsera de 5 à 9 Mo, soit sensiblement moins que Java ou .Net
Côté performances, JIT+Webkit en sus des autres technologies assez éprouvées (Flash, Flex, Html, CSS, Javascript, Ajax), on devrait avoir de très bon résultats.
Une belle bataille en perspective, et un concurent de plus poussant vers l'ouverture...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Une pièce du puzzle
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 8.
et concurrent de Mozilla avec Xulrunner !!
XulRunner permet de faire ce que fait Appollo (d'ailleurs Flex est une copie de XUL). http://xulfr.org/wiki/XulRunner
Bref, XulRunner permet de lancer des applis faites avec XUL / HTML / SVG / XBL / Javascript / python / Ajax et toutes l'api XPCOM de gecko
[^] # Re: Une pièce du puzzle
Posté par spotty . Évalué à 1.
Quelle est la différence entre Appolo et ActionScript ? Les objectifs ont l'air similaire
http://linuxfr.org/~spotty/23027.html
[^] # Re: Une pièce du puzzle
Posté par Ontologia (site web personnel) . Évalué à 6.
Ca sera surement pas mal propriétaire malheureusement, mais ça sera multi plateforme, sinon ça n'a aucun intérêt. C'est le discours de Kevin Lynch, le vice-président d'Adobe.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Une pièce du puzzle
Posté par iznogoud . Évalué à 4.
C'est d'ailleurs cette multiplicité de composants a tambouiller ensemble, qui m'a fait abandonner l'idee de regarder plus avant le xul & tout ce qui traine autour.
[^] # Re: Une pièce du puzzle
Posté par golum . Évalué à 3.
S'il est de bon ton de critiquer Java et ses techno associées pour leur aspect proprio et leur hypothétique ouverture. Que doit-on alors penser de Flex
Ne serait-ce donc pas plus profitable d'améliorer Xulrunner que de le critiquer.
[^] # Re: Une pièce du puzzle
Posté par iznogoud . Évalué à 3.
Améliorer Xulrunner ? J'en serais bien incapable.
Améliorer Xulrunner dans le "bon" sens, pour moi, reviendrait à mon avis proposer un IDE capable d'ajouter une abstraction (gigantesque) capable de masquer l'usage du plus grand nombre de techno possibles.
Prenons la liste de Laurent :
XUL / HTML / SVG / XBL / Javascript / python / Ajax et toutes l'api XPCOM de gecko
Un IDE+framework devrait être capable, pour rendre xulrunner "technologiquement accessible" de supprimer la nécessité de connaître XUL+SVG+XBL+Ajax, et de n'avoir plus qu'une interface pour faire tout ça.
Un parallèle tout bête : ruby on rails, qui est vachement à la mode, te permet de faire de l'Ajax sans toucher à une ligne de javascript. Tu dois connaître le ruby et le HTML. J'aime développer les parties utiles d'une application avant toute chose. XUL me donne l'impression de devoir passer un temps fou sur les détails, avant de pouvoir commencer à coder la partie rellement utile.
Donc, dans notre cas, l'Ajax serait interfacé dans le framework avec des appels simples à des routines. Le XUL serait plutôt à comparer à une sorte d'interface builder (Mac) ou son équivalent GNUStep dont j'ai oublié le nom.
Typiquement, tout ce qui est interface devrait être wysywygable : si je veux faire une application efficace, rapidement, avec xulrunner, je n'ai pas envie de m'agacer avec les détails. Quitte à retoucher un chouilla le code derrière si j'en ai vraiment besoin et que j'ai quelques notions.
Le XUL et xulrunner sont une formidable idée, mais l'accès est réellement rébarbatif. Et améliorer Xulrunner et l'environnement qui tourne autour nécessite une connaissance poussée de tous les domaines qui y touchent, et donc il faut y toucher un jour, ce que je me refuse plus ou moins à faire.
Je préfère très largement me faire une interface à l'ancienne, qui n'utilisera qu'un seul langage, mais que je maitrise, plutot que d'essayer de devoir jongler avec une dizaine de technologies juste pour avoir une fenêtre de texte dans une frame qui se rafraichit toutes les 10 secondes, une barre d'url et un bouton de rafraichissement manuel.
La plus grande avancée pour moi, que pourrait avoir XUL, et qui pourrait me faire changer d'avis, serait d'avoir un interface builder pour XUL.
[^] # Re: Une pièce du puzzle
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Ouai alors là, tu exagère pas mal. Les milliers d'extensions qui existent pour Firefox montre qu'il ne faut pas des connaissances aussi poussées que ça.
Et puis tu parles de X langages à apprendre.
Mais tu oublie de dire que dans ton langage avec X libraries, il faut bien apprendre aussi les apis de tes X libraries.
Franchement, pour faire du dessin 2D par exemple, je ne vois pas de différence entre apprendre une api Java et apprendre une API XML (SVG).
C'est une illusion "d'optique" que de voir en un ruby, un java ou autre, que c'est plus simple parce qu'il y a soit disant qu'un langage.
XML = un langage. Et chaque "API" est représenté par une grammaire.
[^] # Re: Une pièce du puzzle
Posté par iznogoud . Évalué à 5.
Moi, pour ce que j'ai vu : j'ai voulu faire une page en XUL. Il a fallu pour ça, du XML, du js, du css, du html, du rdf. La meme chose avec une structure plus "classique" de page web : js, css, html. J'ai deux éléments, XML certes, mais dont il faut connaître le schéma (faire des aller retour vers la doc pour comprendre comment qu'on actualise un Tree -par exemple- n'est pas une option : je veux que ma page marche, et qu'elle soit prête à temps). D'ailleurs à la même époque, j'en connais qui avaient fait une interface web en XUL. Ça date de 2 ans. L'interface n'est plus accessible avec les dernières versions de Firefox -du moins sous windows, cad la cible visée, et solaris- (la 1.5 plantait déjà, la 2.0 aussi, avec un pourcentage d'occupation mémoire assez important). Mon appli web js/css/html classique, elle, tient toujours.
X langages : oui, tous ou presque se résument à du XML, du js, et 2/3 trucs. Mettons que je maîtrise le XML. Il faut que j'apprenne toutes les grammaires liées à chaque XML, et celles-ci ne sont pas toujours intuitives (pour moi, et c'est purement subjectif).
Imaginons : je veux faire une visionneuse d'images png :
avec Xulrunner&Co, il faut que j'installe Xulrunner (facile, quoique mon dernier essai sous mac os, qui remonte à un peu plus d'un an, n'avait pas du tout été concluant, mais je crois savoir que ça a fortement progressé de ce côté là). Il me faut ensuite comprendre/connaître toutes les grammaires, apprendre au minimum le js, css, html. Il y a au minimum 2 langages (js, XML), et plusieurs API/grammaires.
Avec un bon vieux perl, je dois installer perl (soit), tk (par exemple). Ensuite, je dois apprendre perl, et comprendre/connaître juste l'api de base de tk. Il n'y a qu'un langage, et une api.
Pour moi, y'a pas photo : je connais assez de js, css, html, et assez de perl, pour penser aller plus vite à faire mon appli en perl/tk qu'en xul. Et il existe des perl2exe.
Chacun a ses avantages, et ses inconvénients. C'est pour ça que je dis que XUL est une idée formidable, mais ça ne me convient absolument pas. D'autant que j'ai dans de nombreux langages des générateurs qui me permettent de construire la base de mes sources plus rapidement.
C'est aussi en ça que je dis que XUL pêche par son absence de combinaison IDE/Framework.
Pour finir : je persiste : si je veux améliorer Xulrunner en réalisant par exemple une sorte d'IB à la XCode/GNUStep, il faut quand même avoir plus que de sérieuses bases dans l'ensemble des technos mises en oeuvre. Et ça, ce n'est clairement pas accessible à tout le monde.
Conclusion : collaborer à des projets comme XUL, c'est une super méthode d'apprentissage pluri-disciplinaire avant de pouvoir maîtriser l'engin.
[^] # Re: Une pièce du puzzle
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Pour maitriser le minimum, il faut pas plus que dans apollo :
apollo propose Flash, Flex, Html, CSS, Javascript, Ajax
xulrunner propose SVG, XUL, Html, CSS, Javascript, Ajax (et d'autres choses mais tout n'est pas obligatoire).
Sachant que Flex = XUL like, et que flash, faut l'apprendre aussi au même titre que SVG.
Donc je vois pas bien en quoi ce sera plus compliqué d'apprendre les langages en question dans xulrunner...
(reste le manque d'un environnement de dev wysiwyg, mais y a dejà des plugins eclipse pour faciliter le dev d'appli xulrunner.)
[^] # Re: Une pièce du puzzle
Posté par iznogoud . Évalué à 2.
Alors oui, bon, apollo, je n'ai jamais pu tester, mais je suis d'accord avec l'un des commentaires d'avant : c'est excessivement prometteur en terme de fonctionnalités.
Ça me donne toujours l'impression que le libre a de nombreux outils puissants. Tres puissants. Efficaces. Mais mis bout à bout, ça devient beaucoup moins fun. Quand je vois l'environnement de développement proposé par apple (xcode) et microsoft (visual), je me dis qu'on n'a pas encore atteint ce niveau. Peut-être est-ce du a la multiplicité des langages et technologies : là où apple se concentre sur objective-c et cocoa/carbon, on se retrouve avec un nombre infini de langages, d'api, toutes différentes. Qu'il faut réussir à interconnecter.
(et voilà, je pars encore en live... Faudra un jour que j'apprenne à ne pas écrire au fil de ma pensée :D)
[^] # Re: Une pièce du puzzle
Posté par Ontologia (site web personnel) . Évalué à 5.
Les gens restent coincés sur vi/emacs.
Ces deux logiciels sont très puissant, mais c'est pas un AGL où je peux gérer la base de données, dessiner l'IUH, couplé à une doc véritablement claire, aidé d'assistants d'écriture de code.
Bon oui, ya Eclipse, mais ça va pas aussi loin quand même.
Et j'ai pas d'équivalent à Flash pour faire du Svg.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Une pièce du puzzle
Posté par boubou (site web personnel) . Évalué à 2.
Aussi loin que quoi ? Eclipse a quelques défauts (on se perd dans l'interface et il faut bien 1Go de mémoire pour être à l'aise), mais j'ai du mal à voir ce qu'il ne fait pas...
[^] # Re: Une pièce du puzzle
Posté par Olivier Faurax (site web personnel) . Évalué à 3.
Mais Xulrunner utilisera aussi Tamarin.
En fait, Mozilla et Adobe mettent en commun leurs efforts pour créer une VM pour concurrencer Java et .Net.
A mon avis, leur principal avantage sera que cette VM servira en même temps pour les applis "web (n+1).0" et pour les applis locales.
Java avait essayé ça, mais la partie web (applet) n'a pas bien marché (on en voit plus tellement).
A mon avis, voici quelques raisons :
- il faut installer le plugin
- il faut tout le JRE pour que le plugin fonctionne
- la JVM Microsoft arrange pas la perception de la technologie ("Tu as Java ?" "Oui, mais ça marche pas bien", alors que le Java en question était celui de MS, j'ai eu le cas il y a 2 jours)
Là, on a plus de chances que ça marche : la VM est installé avec le navigateur dans la cas de Firefox, ou avec le player Flash pour les autres.
[^] # Re: Une pièce du puzzle
Posté par Yannick (site web personnel) . Évalué à 1.
L'environnement d'éxecution Java (JRE) pèse moins de 16 Mo, programme d'installation compris. A ne pas confondre avec l'environnement de développement (JDK) (50Mo).
Certe, c'est plus gros que 9 Mo, mais ça reste petit.
[^] # Re: Une pièce du puzzle
Posté par wismerhill . Évalué à 3.
D'ailleurs, appollo sera-t-il seulement destiné au développement d'autre chose que des applications graphiques?
[^] # Re: Une pièce du puzzle
Posté par Gniarf . Évalué à 1.
# impémentation ou implantation ?
Posté par Mathieu . Évalué à 0.
Doit-on utiliser le terme "implanter" ou "implémenter" ?
D'après http://linux-france.unixtech.be/prj/jargonf/I/impleacmentati(...) il y a une différence mais "implémenter" ne serait pas juste un angliscisme? :-s
[^] # Re: impémentation ou implantation ?
Posté par Joël SCHAAL . Évalué à 4.
[^] # Re: impémentation ou implantation ?
Posté par boubou (site web personnel) . Évalué à 2.
[^] # Re: impémentation ou implantation ?
Posté par plic . Évalué à 4.
Si. Comme "mature".
La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham
[^] # Re: impémentation ou implantation ?
Posté par Gohar . Évalué à 2.
Pour "to implement", on peut utiliser "mettre en oeuvre".
# Une seule réponse :
Posté par Guillaume . Évalué à -1.
# Moi j'ai pas confiance
Posté par Zakath (site web personnel) . Évalué à 9.
-->[ ]
[^] # Re: Moi j'ai pas confiance
Posté par gnujsa . Évalué à 2.
http://www.vim.org/scripts/
# Nouveau langage
Posté par espace . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.