Discussion :

[supertonic]

Quand je parle J2EE ou C++/GTK/QT je parle pour comparer des platformes.

Silverlight est un complement pour les applications client rich, mais finallement c'est du .NET ....

c'est comme ce qui est JAVA FX pour java.



j'ai pas dit ça, j'ai dit qu'une tel migration technologique .NET/Silverlight ne sera pas aussi forte que d'autres technologies qui ont commencé sur UNIX/LINUX et que leurs communautés connaissent ces platforms par coeur.

Peut etre que c'est un projet ambicieux, mais pour arriver à une maturité que .NET/SilverLight ont prouvé sur windows, il faut attendre un peu...

euh...JavaFX n'est pas mort, elle vient de naitre, et elle montre jours aprés jours sa force

Pour commencer Silverlight n'est pas du .net...
C'est juste que c'est compatible au niveau source (ya pas toutes les classes non plus hein) ce qui en fait sa force...

JavaFX je vois pas l'interet personellement (pourquoi ils ont inventé un language puisque l'interet c'était le language java en lui même.

Moonlight me paraît super personnelement, mais je n'ai jamais testé n'ayant pas de linux en desktop.

[Firwen]

Moonlight a encore pas mal de chemin à faire, il lit par exemple assez mal les démos de sliverlight 2 qui sont assez "basiques".

Moonlight a par contre l'avantage d'apporter Sliverlight sur d'autres plateformes non supportées par MS : système embarqués, telephones portables smartphones, etc....

Une chose par contre risque d'être un frein majeur pour la technologie :

Y-a-t-il des brevets protégeant Sliverlight au même titre qu'ASP.NET par exemple ? et dans ce cas est-ce que Moonlight peut être menacé ?

[Skyounet]

et dans ce cas est-ce que Moonlight peut-être menacé ?

Moonlight étant supporté par Microsoft je dirais non.

[lunatix]

autant microsoft s'est engagé a ne pas attaquer la partie de mono qui implemente C# (la version normalisée) : d'ailleurs mono va etre refactoré de maniere a separer clairement ce qui est protégé de ce qui ne l'est pas

autant, ils n'ont rien dit pour moonlight. Seuls sont protégés les utilisateurs de suse linux il me semble, et ceux qui téléchargent moonlight sur le site de novell

[smyley]

autant, ils n'ont rien dit pour moonlight. Seuls sont protégés les utilisateurs de suse linux il me semble, et ceux qui téléchargent moonlight sur le site de novell

La question devrais être abordée différemment : Microsoft à conçu Silverlight pour être un concurrent direct niveau RIA avec les solutions déjà en places (Flash entre autre) et qui sont elles multiplateformes. Et Flash a quand même pas mal d'années d'expériences sur pas mal de plateformes.
Et là, l'opportunité, un groupe indépendant s'accorde à porter Silverlight sur un maximum de plateformes alors sincèrement ce serai se tirer une balle dans le pied que d'empêcher cette propagation. Microsoft à tout intérêt à ce que le projet Mono fonctionne convenablement car c'est une "garantie" d'avoir une technologie multiplateforme à laquelle tout le monde pourra participer et profiter. Donc d'un pur point de vue marketing il n'y a absolument aucun intérêt à embêter les gens de novell quand il s'agit du développement de Mono/Moonlight ...

[Pierre Louis Chevalier]

Ce projet me semble etre un très bon signe pour le succès futur de Silverlight.

Je pense que c'est dans l'intéret de Microsoft de ne pas s'opposer au projet, à moins que Microsoft souhaite utiliser Silverlight comme cheval de troie pour torpiller tout ce qui n'est pas Windows pour conforter son "quasi monopole" sur les stations clientes (hors mobiles et Mac).

[Garuma]

sur le blog de Miguel de Icaza - qui a dirigé le projet - qu'elle est à présent pleinement finalisée.

C'est Chris Toshok qui a dirigé le développement de cette release (rendont à César ce qui appartient à César).

[Archeone]

Merci pour la news très intéressante.

Néanmoins il y a tjrs un point qui m'a chiffonné pour ce qui est de l'implémentation de MoonLight.

Pourquoi ne pas avoir fusionner les équipes MoonLight/Silverlight pour sortir un seul plugin??
Les fonctionnalités de Silverlight sont normalisée après tout? Pourquoi perdre du temps à le réécrire deux fois ce plug in??
Microsoft et Novell aurait pu avoir qu'une seule et même équipe.

[smyley]

Pourquoi ne pas avoir fusionner les équipes MoonLight/Silverlight pour sortir un seul plugin??

Quoi ? tu inciterai Microsoft à racheter novell ou plutôt à racheter une communauté open-source qui réalise le projet Mono & Co ? c'est peut être risqué ...

[Archeone]

Non l'idée serait tout simplement de payer un groupe de développeur. Qui viennent de Microsoft et de Novell pour faire "le" plugin Silverlight.

Ce plugin est normalisé à l'ECMA de toute façon comme le reste du Framework?

Honnêtement tout le monde serait gagnant. Il y aurait 2 fois plus de développeur sur la création/maintenance de Silverlight. Et on aurait un seul plug in, pour un seul produit.
Après bien sur la création de ce plug in devrait être bien sur open source pour qu'il puisse intégrer les distributions linux.

Pour faire une analogie avec le monde de l'open source pour ne pas fonder la fondation "Silverlight" tout comme a été créer la fondation "Mozilla"?(Faut pas se leurrer Mozilla et ses 200 employés ils sont subventionner par bon nombre de grosse entreprise(google, amazone....) sinon on aurait jamais eu des produits de cette qualité).

Oui car MoonLight n'est pas créer que par des contributeurs et oui il y a des gens payé pour faire ce plugin même si celui ci est open source.

Enfin voila c'est peut être bête comme réflexion, mais bon je trouve que l'on perd beaucoup de temps hommes pour pas grand chose.

[Max.Adorable]

Bonjour,

Bonne nouvelle ça. Le projet Mono est pour moi un très bon projet à ça fait plaisir de le voir avancer.

En ce qui concerne MoonLight et Microsoft, il existe un accord entre Novell et Microsoft concernant cette technologie. Notamment Microsoft fournis gratuitement ses codecs propriétaires.

source: http://www.novell.com/fr-fr/products...light_faq.html

Max.

[lex2004]

En ce qui concerne MoonLight et Microsoft, il existe un accord entre Novell et Microsoft concernant cette technologie. Notamment Microsoft fournis gratuitement ses codecs propriétaires.

Effectivement, l'équipe de Moonlight jouit d'une collaboration officielle de la part des ingénieurs de Microsoft. C'est d'ailleurs la première fois que Microsoft apporte un soutient officiel au projet Mono. Avant, il n'y avait qu'une collaboration officieuse entre développeurs de Mono et ceux de .Net.

Maintenant, quant à savoir si porter SilverLight vers Unix est une bonne chose, forcément. Cette technologie étant destinée à être utilisée sur le Web, la moindre des choses c'est qu'elle soit multi-plateforme. Il existe déjà un plugin SilverLight pour Windows et Mac OS X. Microsoft a préféré laisser le soin aux équipes de Novell d'implémenter ce plugin sous Linux. Même si cela se traduit par une lenteur de développement considérable, c'est toujours mieux que rien et cela permet aussi au projet Mono d'acquérir de la maturité.

Pour ceux qui évoquent Java ou C++ chaque fois qu'il est question de .Net (ou d'une technologie liée), rappelons toutes fois que Java n'est ni libre, ni ouvert. Pas plus que .Net en tout cas. C'est une technologie propriétaire de Sun Microsystems (et désormais d'Oracle Corporation) qui se réserve seul le droit de décider de son évolution (ne me parlez surtout pas des JSR, ça ne remplace pas une norme). Quant à C++, c'est un langage difficile à apprendre et difficilement utilisable dans le développement d'applications d'entreprise. Les développeurs contemporains ont besoin de langages plus évolués. Java et C++ ont leurs qualités et leurs défauts comme toute œuvre humaine. Et le fait que ces technologies existent ne signifie pas que d'autres technologies de développement multi-plateforme ne devraient pas voir le jour.

Une initiative comme Mono est très louable; essentiellement du fait qu'elle propose aux développeurs une implémentation du standard CLI qui survivrait à une disparition éventuelle de Microsoft. D'autres part, elle permet aux développeurs Unix de profiter d'un environnement de développement qui ne sacrifie pas à la qualité pour préserver une utopique portabilité et qui ne demande pas qu'on parcoure plusieurs milliers de pages de manuel pour s'y mettre.

J'avais déjà installé le plugin Moonlight 1.0 sur mon firefox (sous Mandiva Linux). Inutile de dire que ce n'était pas suffisant la majeur partie du temps. Je suis ravi de voir que la deuxième version est sur le point de voir le jour.

[lunatix]

tu dis n'importe quoi, java est disponible sous license GPL with classpath exception -> http://openjdk.java.net/

[h472009]

rappelons toutes fois que Java n'est ni libre, ni ouvert. Pas plus que .Net en tout cas.

ça me fait rire

bref, aucun n'a dit que java ou c++ n'ont pas d'inconvénients, mais au moin sous une platform UNIX/LINUX, ils ont montré une maturité incomparable, et ont des communautés trop large pour supporter et faire évoluer.

En plus qui a dit que le c++ est difficile a apprendre, tu pense que microsoft a inventé la syntaxe de C# qui est a 80% celle de c/c++/java??? ou une fois entendre le mot "pointeur" tous le monde a peur ??? on peut faire du c++ sans faire des pointeurs comme même!!!.

[lex2004]

java est disponible sous license GPL with classpath exception[/url]

Tout le monde a entendu parler de l'OpenJDK. Ce n'est pas vraiment une revolution. Ce n'est qu'une implémentation libre du JDK fournie pas Sun et qui se conforme aux spécifications de l'éditeur en la matière. Le problème c'est que ces spécifications ne remplacent pas une norme. Java est donc toujours contrôlé de près par Sun. Dis-toi bien que tu n'as pas le droit de faire n'importe quoi avec l'OpenJDK (essaie de remplacer un paquetage par exemple et tu verras si ton Java est toujours reconnu comme tel).

Le fait que Sun se soit chargé lui-même de fournir l'OpenJDK prouve à quel point il est difficile à un opérateur tiers d'implémenter son propre JDK. En fait, l'OpenJDK n'est pas la première implémentation open-source de Java (tu peux t'en convaincre pendant l'installation d'un Linux). Mais c'est la seule qui soit pertinente (parce quelle est fournie par Sun). Les autres n'ayant pas convaincu les développeurs.

D'autre part, on peut croire que l'idée de fournir un Java open-source a eu deux principales motivations: la faillite imminente et la nécessité de faire face à Mono. On attend toujours une vraie norme Java

[lex2004]

qui a dit que le c++ est difficile a apprendre, tu pense que microsoft a inventé la syntaxe de C# qui est a 80% celle de c/c++/java??? ou une fois entendre le mot "pointeur" tous le monde a peur ??? on peut faire du c++ sans faire des pointeurs comme même!!!.

Ce qui rend C++ difficile, ce n'est pas seulement la présence des pointeurs (et autres lourdeurs). Mais principalement le fait que sa bibliothèque standard soit très pauvre. Pour pouvoir développer concrètement en C++, le développeur doit donc s'en remettre à un ou plusieurs frameworks tiers donc l'apprentissage s'ajoute à celui déjà très complexe du langage lui-même. Autres fois, les éditeurs d'EDI résolvaient ce problème en intégrant un framework propriétaire dans leur environnement ( et éventuellement quelques nouveaux mots-clés). Cela a eu pour inconvénient majeur qu'on se retrouve avec une telle diversité de C++ qu'on pouvait se demander s'il s'agissait toujours du même langage.

Récemment, quelques frameworks multi-plateformes et indépendants de tout EDI ont vu le jour. Mais ils posent toujours le problème de la nécessité de réapprendre le langage. D'autres part, il est devenu très difficile à un programmeur novice de configurer un environnement de développement fonctionnel en C++ (c'est la contre-partie de la disparition progresive des EDI comme BCB)

[Deadpool]

Bon ça digresse, ça digresse, donc à mon tour je ne peux pas m'en empêcher.

Tout le monde a entendu parler de l'OpenJDK. Ce n'est pas vraiment une revolution. Ce n'est qu'une implémentation libre du JDK fournie pas Sun et qui se conforme aux spécifications de l'éditeur en la matière. Le problème c'est que ces spécifications ne remplacent pas une norme. Java est donc toujours contrôlé de près par Sun.

Dis, tu as entendu parler du Java Community Process (site officiel)?

C'est une organisation fondée par Sun dont le but de faire évoluer le langage en impliquant toutes les parties prenantes (donc Sun n'est pas le chef). A cette fin, des Java Specification Request (les fameuses JSR) sont émises, puis examinés et validés si elles sont reconnus comme pertinentes.

Parmi les membres, outre Sun, y'a par exemple Oracle (bon vu que maintenant Sun appartient quasiment à Oracle c'est normal), IBM, Borland, BEA, Nokia, Sony, etc... mais aussi des fondations du monde du logiciel libre, comme la fondation Apache ou OW2, et même toi si tu veux puisque l'adhésion des particuliers est libre.

Donc dire que seul Sun contrôle Java et que c'est fermé est quelque peu abusé.

Dis-toi bien que tu n'as pas le droit de faire n'importe quoi avec l'OpenJDK (essaie de remplacer un paquetage par exemple et tu verras si ton Java est toujours reconnu comme tel).

Effectivement, pour qu'une implémentation obtienne le droit de s'appeler Java, il existe une suite de tests vérifiant le respect de la spécification Java par l'implémentation. Ces tests ont pour nom TCK.

Le but est clair, faire en sorte que Java soit standardisé et éviter qu'il existe plusieurs Java non compatibles entre eux.

[lex2004]

Dis, tu as entendu parler du Java Community Process? [...] des Java Specification Request (les fameuses JSR) sont émises, puis examinés et validés si elles sont reconnus comme pertinentes. [...] Donc dire que seul Sun contrôle Java et que c'est fermé est quelque peu abusé.

Le principe des JSR c'est: "Propose ce qui te semble bon. Nous l'examinerons. Si nous l'apprécions, nous l'intègrerons peut-être dans une future version du JDK".
Par contre, le principe d'une norme comme CLI ou C++ ISO (oui citons aussi cette norme là), c'est "Voici la liste des fonctionnalités que ton implémentation doit offrir pour être reconnue comme une implémentation valide. Une fois que cette exigence est satisfaite, tu es libre d'ajouter tout ce que tu veux".
Je crois que la différence saute aux yeux. Par ailleurs, Sun se réserve un droit de véto sans nul pareil dans le Java Community Process. C'est juste une sorte de gang de Sun.

[...] pour qu'une implémentation obtienne le droit de s'appeler Java, il existe une suite de tests vérifiant le respect de la spécification Java par l'implémentation [...] Le but est clair, faire en sorte que Java soit standardisé et éviter qu'il existe plusieurs Java non compatibles entre eux.

Si Java était standardisé, les exigences en matière de compatibilité ne pourraient s'appliquer qu'au standard; mais pas sur les extensions. Vouloir que tous les Java soient à 100% compatibles entre-eux c'est implicitement refuser qu'il y ait d'autres Java que celui de Sun. Sinon des répliques à l'identique (dont l'existence serait injustifiée dans ce cas)

[Deadpool]

Le principe des JSR c'est: "Propose ce qui te semble bon. Nous l'examinerons. Si nous l'apprécions, nous l'intègrerons peut-être dans une future version du JDK".
Par contre, le principe d'une norme comme CLI ou C++ ISO (oui citons aussi cette norme là), c'est "Voici la liste des fonctionnalités que ton implémentation doit offrir pour être reconnue comme une implémentation valide. Une fois que cette exigence est satisfaite, tu es libre d'ajouter tout ce que tu veux".

Rien n'empêche de créer certaines extensions (exemple au pif, SWT d'IBM) c'est juste que ça ne peut pas être compris dans la distribution standard de Java. Mais tu peux le proposer à côté. Ca change pas grand chose dans l'esprit.

Par ailleurs, Sun se réserve un droit de véto sans nul pareil dans le Java Community Process. C'est juste une sorte de gang de Sun.

Sun se réserve rien du tout, les JSR sont validé par le comité exécutif du JCP qui contient des membres élus de ce même JCP. Ce ne sont pas que des membres de Sun. C'est donc un processus démocratique.

Si Java était standardisé, les exigences en matière de compatibilité ne pourraient s'appliquer qu'au standard; mais pas sur les extensions. Vouloir que tous les Java soient à 100% compatibles entre-eux c'est implicitement refuser qu'il y ait d'autres Java que celui de Sun. Sinon des répliques à l'identique (dont l'existence serait injustifiée dans ce cas)

Non, ça évite que des entreprises comme Microsoft rajoute en loucedé des packages uniquement fonctionnel sur sa plateforme en les faisant passer pour des fonctionnalités standard de Java.

Il ne faut pas oublier que Java est "vendu" comme étant portable, c'est pour cette raison que le respect de la spec est primordial.

[lex2004]

Rien n'empêche de créer certaines extensions (exemple au pif, SWT d'IBM) c'est juste que ça ne peut pas être compris dans la distribution standard de Java. Mais tu peux le proposer à côté. Ca change pas grand chose dans l'esprit.

Si ça change beaucoup. Il y a une grande différence entre intégrer une fonctionnalité dans le JDK et la proposer en option. C'est plus flagrant quand la fonctionnalité que je veux ajouter porte sur le langage lui-même et non sur sa bibliothèque.

Sun se réserve rien du tout, les JSR sont validé par le comité exécutif du JCP qui contient des membres élus de ce même JCP. Ce ne sont pas que des membres de Sun. C'est donc un processus démocratique.

Donc Sun pourrait être exclu du JCP?

Non, ça évite que des entreprises comme Microsoft rajoute en loucedé des packages uniquement fonctionnel sur sa plateforme en les faisant passer pour des fonctionnalités standard de Java.

Mais Visual C++, Borland C++ et autres contiennent déjà plein d'extensions propriétaires qui ne sont pas portables. Est-ce une violation du standard C++?

Il ne faut pas oublier que Java est "vendu" comme étant portable, c'est pour cette raison que le respect de la spec est primordial.

Si Java était normalisé, les utilisateurs assumeraient que la partie de Java qui fait partie de la norme est portable et que les extensions ne le sont probablement pas. C'est vrai pour beaucoup de langages et ça ne freine absolument pas les ardeurs de certains à les utiliser dans le développement d'applications multi-plateformes.