oui ça s'appelle longhorn, c'est la future version de Windows. Il n'y aura plus de navigateur (sauf IE6 pour question de compatibilité avec les antécedents). tout sera vraiment tout intégré (avec leur système avalon XAML &co).
Et pas de nouvelle version de IE ou assimilé à l'horizon.
Parce que fo leur reconnaitre un truc : ils savent s'adapter au marché
Ah oui ? Ben le marché demande des navigateurs conformes aux standards (cf les enquêtes des developpeurs de IE auprés des utilisateurs) et sécurisés. Ils n'en fournissent toujours pas.
Franchement, les responsables (informatiques ?) qui ont décidé de la mise à jour de leur système mosaique ont vraiment la tête dans la lune.
Quelle idée de mettre un jour tout un système pendant une période plutôt (sur)chargée en activité ! Tout informaticien compétent sait trés bien qu'on ne met pas en prod une application lors de périodes critiques (et surtout pas le vendredi aprés midi ;-), parce que comme le dit la loi de murphi, c'est pendant le week-end, où plus personne n'est là, que la nouvelle appli/site va planté )
Même aprés des dizaines et des dizaines de test
Je ferais remarquer aussi l'un des avantages pour Aston d'avoir mis sous licence libre ce framework : pendant 1 an et demi, j'ai été l'un des contributeurs principaux de ce framework, au sein même d'Aston. J'ai quitté la société il y a quelques temps pour me rapprocher du lezard ;-). Mais cela ne m'empêche pas de continuer de contribuer à Copix (dans une moindre mesure certes, faute de temps).
Tout le monde y trouve donc son compte : moi parce que je peux continuer à bosser sur un projet que j'aime, que je peux continuer à utiliser comme je veux et Aston parce qu'en définitive elle ne perd pas complétement l'un de ses "experts" du projet. Elle continue donc de profiter des améliorations que je pourrais apporter dans le futur.
le chat organisé par les dev de IE montre bien que enormément de personnes veulent du CSS2, mais que finalement, ce n'est toujours pas une priorité chez MS..
La realite c'est que personne ne le fait cet audit, surtout dans un monstre comme Mozilla qui contient des millions de lignes de code.
ça reste à vérifier ça...
Combien de développeurs participent au dev de Mozilla déjà ?
je cite Tristan Nitot :
Des ingénieurs:
400 comptes CVS
150 comptes font un check-in de code par mois
Des testeurs :
10.000 personnes téléchargent nos nightlies
40.000 personnes ont rapporté un bug
2.000 comptes ont des droits avancés
(chiffres de novembre 2003)
Pour IE par exemple, tu as les chiffres ? On peut voir les sources ?
c'est miraculeux d'avoir un CVS, des nightly builds et de faire des code reviews ? A peu pres toutes les grosses boites logiciels font ca depuis plus de 10 ans.
Je m'etonne alors de la médiocre qualité de certains logiciels..
Le jour ou Mozilla aura des procedures aussi strictes que celle en vigueur en ce moment chez MS pour mettre du code
On attend encore les résultats. Rassure moi, ça ne concerne pas l'équipe de IE hein ?
Les procedures decrites sur cette page elles etaient en vigueur chez MS il y a 5-6 ans,
Désolé, je ne peux absolument pas te croire conçernant certains produits de ta firme, en particulier IE.. Faut arreter de se foutre de la gueule du monde là...
Gros gag, combien de gens prennent les nightly builds de Mozilla ?
10 000, comme dis plus haut. C'est déjà certainement plus que chez microsoft.
Combien de gens savent tester un soft ? Combien de gens vont reporter le bug au lieu de ne rien faire ? Combien de ces gens font tous le meme test plutot que tester les fonctions plus complexes et moins utilisees ?
Impossible de te dire. Un certain pourcentage des 10000 qui télécharge les nightly.. Certainement le même que chez microsoft, voir plus... Je ne sais pas. et je doute que tu le saches aussi de ton coté..
N'empeche que si plus de monde peut tester, plus il y a de chance de découvrir un bug, pas vrai ? Et là clairement, que les nightly build soit librement téléchargeable, donne plus de chance à ce que le produit soit stable et robuste qu'un produit qui ne peut être testé que par un groupe restreint d'utilisateur, comme c'est la cas chez microsoft (Si ce n'est pas le cas, je veux bien tester la dernière beta de IE, sans avoir à débourser un sou bien sûr...)
Et quand bien même Microsoft publie parfois des betas de leur logiciels, je te pose les même questions : Combien de ces testeurs lambda vont reporter le bug au lieu de ne rien faire ? Combien de ces gens font tous le meme test plutot que tester les fonctions plus complexes et moins utilisees ?
Tiens d'ailleurs, comment un utilisateur lambda reporte un bug à microsoft ? y a un bugzilla like ? (bugzilla qui n'est pas simple d'accés pour des neophite, certes, mais il a le mérite d'exister et d'être accessible à tout le monde).
Les procedures de test dans le logiciel libre en general(sauf qqe projets) sont un gros _GAG_ compare a ce que MS fait.
Peut-être, mais je ne pense pas que ce soit le cas de Mozilla.
Ca serait bien que l'auteur de la page ait ne serait ce qu'un semblant de connaissance du developpement logiciel sur gros projets avant de passer pour un idiot
ba, il a déjà bossé pour des grosses boites... y en a une d'ailleurs qui s'appelait Netscape... Je pense qu'il sait de quoi il parle.
Et puis, relis bien son billet, il n'affirme pas du tout que ça se passe plus mal que chez mozilla au niveau des processus de developpement, il dit juste comment ça se passe chez Mozilla, et il pose des questions parce qu'il aimerait justement savoir comment ça se passe chez MS.. Tu n'as qu'à lui repondre en commentaire sur son blog..
Tu utilises les mêmes arguments que les pro microsoft, arguments qui ne me semblent pas valable. Ce n'est pas parce que il n'y a QUE quelques millions d'utilisateurs de Mozilla que l'on ne trouve pas de faille... Si il n'y avait que quelques centaines encore... mais là, faut arreter hein ?
De plus, je te rappelle que mozilla est open source, donc ceux qui en ont les compétences peuvent chercher les failles beaucoup plus facilement que celles de IE.
60% de serveurs web sous apache ne veut pas dire forcément 60% de serveurs web sous linux.... il y en a beaucoup moins que ça des serveurs linux... Beaucoup d'apache tournent sous windows
Les compilations des binaires étant faites automatiquement par leur système tinderbox, à partir du cvs, les versions corrigées compilées (officieuses) sont apparues quelques minutes aprés la correction.
> Et surtout, il faudra voir comment les utilisateurs vont être informées et vont télécharger cette nouvelle version
ba là, c'est comme tout.. si l'utilisateur ne se tient pas au courant, il ne pourra pas mettre à jour.. Mais t'inquiete pas, la fondation communique... http://www.mozilla.org/(...)
et les blogs relaient l'info ;-)
Faut voir la moyenne des résultats à ce test. Celle des spectateurs était affolante : seulement 1 réponse sur 2 de bonnes. Celle des téléspectateurs était meilleure (je ne sais plus) mais était loin du minimum à avoir pour être reçu.
baa, examens, mariage, profiter du beau temps, alims qui claquent, manque de motivations, autres choses prioritaires... tout ça quoi... Pas évident d'être toujours à l'affut de choses crétines ;-)
Avec une communauté d'agités comme ca, spip-agora n'est pas prêt de merger avec SPIP !!
C'est clair. L'un des objectifs de spip-agora : avoir un CMS qui soit accessibles et conformes au standards.
Comme chacun le sait, avec certaines reactions trollesques des dev de spip comme celle ci http://www.uzine.net/article1979.html,(...) il ne faut surtout pas s'etonner du fork. En particulier les dev de spip.
Il est clair qu'ils n'ont pas voulu aller dans le sens des besoins de spip-agora, donc : fork.
Quelque chose de bien naturelle dans les logiciels libres en fait ;-)
>Je n'ai jamais compris pourquoi il ne se contente pas d'exécuter tout bêtement du bytecode Java provenant du serveur et exécuté dans une sandbox ? çà eviterai
d'avoir à réecrire, le code de la logique métier des objets du coté client.
tout simplement parce que la logique metier, elle n'a rien à faire dans la couche "presentation", coté interface quoi...
Faut pas tout mélanger... Si les méthodes de conception en sont arrivé à séparer en couche les différentes parties d'une applis, ce n'est pas pour rien.
Quant à executer du bytecode java provenant du serveur, ça existe déjà depuis des lustres, ça s'appelle des applets. Peut être en étudiant le résultat de l'épopée de cette techno, tu comprendra pourquoi on n'utilise plus du bytecode java coté client.
> La communauté de Mozilla veut faire trop compliqué pour répondre à un besoin qui n'est en soit pas si compliqué que çà.
je te propose de t'informer plus sur le pourquoi du comment, notament, historiquement, pourquoi Mozilla a inventé XUL et co, et pour quel usage...
> Je ne doute pas, mais tu seras quand même obligé de collecté toutes les données de ton interface à la main pour construire ton message XML que tu transmettra au serveur.
Oui, et en utilisant une partie de ton cerveau, tu pourra même te réaliser une petite bibliothèque qui te permettra de faire tout ça en 2 lignes de code. (ou au pire, en récuperer une déjà toute faîte..)
> De même, tu effectuera un traitement similaire pour la réception du retour. Je me trompe ?
non, et alors ?? ça s'appelle faire appel à des services web (tu sais le truc qui te permet justement de tout garder tes objets metiers coté serveur, et de pouvoir les utilisé depuis n'importe où : appli web, client desktop etc...)
> Dans un autre langage, tu effectuera la même opération côté serveur.
euh, excuse moi, mais le serveur il est toujours là pour faire des traitements metier.
Je dirais même que ton appli en xul sera plus performante et le serveur moins surchargé, car il n'a plus à regénérer l'interface graphique d'un formulaire à chaque fois que l'on veut changer un truc dans le formulaire.
Il fait juste les traitements qu'on lui demande de faire au travers de services web.
(Mozilla sait faire du SOAP nativement, donc à priori, il n'y as pas 15000 lignes de code JS à écrire pour faire appel à un web service afin de poster le contenu d'un formulaire et récuperer l'éventuel résultat,dans le cas d'un formulaire de recherche par exemple)
>Dans un formulaire HTML, tu n'as pas besoin d'effectuer la première opération. Elle correspond à la reconstruction de l'interface avec le rechargement de la page.
et tu trouve ça efficace ?
moi non. et pas super friendly pour l'utilisateur.
essaye http://mab.mozdev.org.(...)
exercice : faire la même chose classiquement en HTML/PHP, tout en étant aussi friendly, ergonomique etc... (on comparera le nombre de ligne de code en JS ok ? ;-)
> Si le langage associé à la description de ton interface dans un langage tel que XUL et le même que celui executé du côté serveur. Tu pourrais envisager d'écrire une seul fois l'objet partager entre le serveur et le client rich. Les echanges de données entre les deux parties se ferait simplement par une serialisation et deserialisation de ton objet.
t'es un tueur toi non ? Ta dévise ne serait-elle pas "pourquoi faire simple quand on peut faire compliqué" ?
> L'avantage de Microsoft avec XAML, c'est qu'ils ne se poseront même pas la question vu que tout est déjà integré dans .Net.
Ils ont juste à écrire le browser, la plateform fera déjà le reste !
> A mon avis, çà vient justement du fait qu'il ne reponde pas au besoin.
hum...
Si XUL n'est pas si connu, c'est tout simplement à cause de la politique de mozilla.org, nullement le fait que cela ne répondent pas au besoin.
Les developpeurs de mozilla.org n'ont pensé pendant des années qu'à developper XUL uniquement dans l'optique de faire leur browser. Et en aucun cas dans l'optique de pouvoir faire d'autres applis avec.
Cela ne fait que quelques mois qu'ils commencent à comprendre que les technos qu'ils ont développé ont un potentiel énorme, en dehors de leur browser.
> Néanmoins reconnait qu'il y a bcp plus de personne maitrisant Flash et ActionScript que dans les technos de Mozilla.
> Le problème, c'est que XUL/EcmaScript ne repondent pas aux besoins des entreprises.
permet moi d'en douter
>Tu pourras faire une interface graphique à peine plus complexe qu'avec du XHTML/CSS/EcmaScript.
ben voyons.
Un menu déroulant par exemple.
En xul : 2-3 balises à ta disposition.
En xhtml : 2-3 balises, + du code javascript dans tout les sens.
Désolé, mais il n'y a pas photo. On peut réaliser des interfaces VRAIMENT complexe avec XUL, sans que ce soit réèllement difficile.
> Mais si tu veux pouvoir réutiliser tes composants afin de les mettre à profit à d'autre endroit d'un projet. Tu ne pourra qu'en acquerant des compétences dans d'autre technologie et la tu te retrouves à te plonger dans la description: XPCOM , XBL, création de XPI.
euh... je ne vois pas ce que viennent faire XPCOM et XPI pour faire des composants graphiques réutilisables.
Dans le cas d'une appli web, tu n'as pas vraiment besoin de XPCOM ou XPI. Les traitements metiers se font toujours coté serveur web, en php java ou autre. Bref, ça ne change pas beaucoup de maintenant. Il y a juste l'interface qui change.
>Sans compter, les problèmes de déploiements de composants XPI du aux différentes versions de Mozilla.
oui mais ça, ça n'a rien à faire dans des applis web.
>A çà, tu rajoutes le développement du coté serveur dans un autre langage et tu te retrouves avec un beau mic-mac.
je ne vois pas en quoi c'est plus micmac que maintenant.
Une appli web actuellement, c'est quoi ?
HTML + CSS + JS + PHP/JAVA/autre
Une appli web en xul, c'est quoi ?
XUL (+XBL) + CSS +JS + PHP/JAVA/autre
où vois-tu que c'est plus le bordel ?
> Ou chaque développeur est irremplaçable car il n'y a que lui qui maitrise une technologies employé dans le projet.
tout développeur web maitrise un minimum HTML, CSS, JS, et PHP/JAVA/autre
Sous pretexte qu'on remplace le HTML par du XUL, il ne saurait plus rien faire ? ne saurait plus faire que du JS ou que du PHP ou... ???
>A çà, tu rajoutes toutes les parties codes qui vont être réecrite plusieurs fois. Par exemple, un objet métier et son comportement une fois en JavaScript côté client , une fois Php ou en Java côte serveur.
Ahh ? parce que pour toi, un objet metier fait parti de l'interface graphique ???? boudiou, tu as des méthodes de travail plutôt bordelique ! je comprend maintenant que tu t'en sort pas avec HTML +CSS +js + php/java/autre tout ensemble !
>ref, tu changes un attribut ou comportement de ton objet métier, tu modifie le projet à 2 endroits différents dans deux langages différents.
pas plus que pour une appli web classique
>De plus, Microsoft, et Macromedia propose un système reposant sur une seul implémentation. J'espère que Mozilla, et Opera s'arrangeront aussi pour avoir qu'une seul implémentation...
Ah ba oui, reposer sur une techno propriétaire, c'est en effet plus facile d'avoir qu'une seule implementation, que quand on essaie de se reposer sur des technos standards, où il faut s'entendre avec tout le monde pour que ça fonctionne...
Oui mais faut voir les résultats aprés...
> Bref du bonheur.
tu l'as dit bouffi. mais renseigne toi un peu plus sur XUL. Je crois qu'il te manque quelques infos pour pouvoir faire une comparaison objective qui ne tourne pas au troll.
mince alors... j'avais des VIP et je ne le savais pas :-)
bon, sinon désolé si je t'ai endormi... (jamais facile de toute façon d'assister à une conf aprés déjeuner, et je ne suis pas le genre d'orateur qui sait reveiller les foules )
certains irréductibles essayent encore de faire des sites Internet qui passent partout, à grand renfort d'heures supplémentaires et d'arrachages de cheveux.
OH ! Un troll !
arrachage de cheveux quand on débute. (normal, il faut désormais apprendre html et css ! ainsi que les petites astuces pour que ça passe partout... tu parles d'une histoire !)
Mais ensuite, ça passe tout seul quand on commence à maîtriser.
(bref, c'est comme tout hein..)
M'enfin vouloir faire en sorte que ça passe à la fois sous IE4 et sous IE6/moz/truc, faut vraiment être un masochiste et avoir justement du temps à perdre. Parce que c'est vraiment de la perte de temps que de rendre "compatible" un site conçus avec les standards, avec un navigateur qui comprend à peine les standards.. Et c'est d'autant plus de temps de perdu que quasiement plus personne ne l'utilise...
Commencer la compatibilité avec la version 5.0, ça va, mais avec le 4, c'est débile.
(ou alors appliquer une astuce css pour pas que les feuilles de styles s'appliquent pour IE4, et là ça passe super nickel ;-) )
[^] # Re: Ouille!
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Nouvelle vulnérabilité pour Mozilla/Firefox. Évalué à 2.
Et pas de nouvelle version de IE ou assimilé à l'horizon.
Parce que fo leur reconnaitre un truc : ils savent s'adapter au marché
Ah oui ? Ben le marché demande des navigateurs conformes aux standards (cf les enquêtes des developpeurs de IE auprés des utilisateurs) et sécurisés. Ils n'en fournissent toujours pas.
[^] # Re: errata
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Tiens comme c'est etrange ?. Évalué à 1.
# quelle bétise aussi
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Que se passe-t-il à la SNCF ?. Évalué à 5.
Quelle idée de mettre un jour tout un système pendant une période plutôt (sur)chargée en activité ! Tout informaticien compétent sait trés bien qu'on ne met pas en prod une application lors de périodes critiques (et surtout pas le vendredi aprés midi ;-), parce que comme le dit la loi de murphi, c'est pendant le week-end, où plus personne n'est là, que la nouvelle appli/site va planté )
Même aprés des dizaines et des dizaines de test
# ps
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Sortie de Copix 2.1. Évalué à 8.
Tout le monde y trouve donc son compte : moi parce que je peux continuer à bosser sur un projet que j'aime, que je peux continuer à utiliser comme je veux et Aston parce qu'en définitive elle ne perd pas complétement l'un de ses "experts" du projet. Elle continue donc de profiter des améliorations que je pourrais apporter dans le futur.
Vive les logiciels libres :-)
[^] # Re: linux n'est pas impacté
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Correction d'un problème de sécurité sous mozilla firefox et thunderbird. Évalué à 2.
http://blog.ebrahim.org/media/msie_teamchat_20040608.log(...)
http://blogzinet.free.fr/index.php?2004/07/10/272-LogDuChatAvecLequ(...)
[^] # Re: linux n'est pas impacté
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Correction d'un problème de sécurité sous mozilla firefox et thunderbird. Évalué à 7.
ça reste à vérifier ça...
Combien de développeurs participent au dev de Mozilla déjà ?
je cite Tristan Nitot :
Des ingénieurs:
400 comptes CVS
150 comptes font un check-in de code par mois
Des testeurs :
10.000 personnes téléchargent nos nightlies
40.000 personnes ont rapporté un bug
2.000 comptes ont des droits avancés
(chiffres de novembre 2003)
Pour IE par exemple, tu as les chiffres ? On peut voir les sources ?
c'est miraculeux d'avoir un CVS, des nightly builds et de faire des code reviews ? A peu pres toutes les grosses boites logiciels font ca depuis plus de 10 ans.
Je m'etonne alors de la médiocre qualité de certains logiciels..
Le jour ou Mozilla aura des procedures aussi strictes que celle en vigueur en ce moment chez MS pour mettre du code
On attend encore les résultats. Rassure moi, ça ne concerne pas l'équipe de IE hein ?
Les procedures decrites sur cette page elles etaient en vigueur chez MS il y a 5-6 ans,
Désolé, je ne peux absolument pas te croire conçernant certains produits de ta firme, en particulier IE.. Faut arreter de se foutre de la gueule du monde là...
Gros gag, combien de gens prennent les nightly builds de Mozilla ?
10 000, comme dis plus haut. C'est déjà certainement plus que chez microsoft.
Combien de gens savent tester un soft ? Combien de gens vont reporter le bug au lieu de ne rien faire ? Combien de ces gens font tous le meme test plutot que tester les fonctions plus complexes et moins utilisees ?
Impossible de te dire. Un certain pourcentage des 10000 qui télécharge les nightly.. Certainement le même que chez microsoft, voir plus... Je ne sais pas. et je doute que tu le saches aussi de ton coté..
N'empeche que si plus de monde peut tester, plus il y a de chance de découvrir un bug, pas vrai ? Et là clairement, que les nightly build soit librement téléchargeable, donne plus de chance à ce que le produit soit stable et robuste qu'un produit qui ne peut être testé que par un groupe restreint d'utilisateur, comme c'est la cas chez microsoft (Si ce n'est pas le cas, je veux bien tester la dernière beta de IE, sans avoir à débourser un sou bien sûr...)
Et quand bien même Microsoft publie parfois des betas de leur logiciels, je te pose les même questions : Combien de ces testeurs lambda vont reporter le bug au lieu de ne rien faire ? Combien de ces gens font tous le meme test plutot que tester les fonctions plus complexes et moins utilisees ?
Tiens d'ailleurs, comment un utilisateur lambda reporte un bug à microsoft ? y a un bugzilla like ? (bugzilla qui n'est pas simple d'accés pour des neophite, certes, mais il a le mérite d'exister et d'être accessible à tout le monde).
Les procedures de test dans le logiciel libre en general(sauf qqe projets) sont un gros _GAG_ compare a ce que MS fait.
Peut-être, mais je ne pense pas que ce soit le cas de Mozilla.
Ca serait bien que l'auteur de la page ait ne serait ce qu'un semblant de connaissance du developpement logiciel sur gros projets avant de passer pour un idiot
ba, il a déjà bossé pour des grosses boites... y en a une d'ailleurs qui s'appelait Netscape... Je pense qu'il sait de quoi il parle.
Et puis, relis bien son billet, il n'affirme pas du tout que ça se passe plus mal que chez mozilla au niveau des processus de developpement, il dit juste comment ça se passe chez Mozilla, et il pose des questions parce qu'il aimerait justement savoir comment ça se passe chez MS.. Tu n'as qu'à lui repondre en commentaire sur son blog..
[^] # Re: linux n'est pas impacté
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Correction d'un problème de sécurité sous mozilla firefox et thunderbird. Évalué à 1.
Tu utilises les mêmes arguments que les pro microsoft, arguments qui ne me semblent pas valable. Ce n'est pas parce que il n'y a QUE quelques millions d'utilisateurs de Mozilla que l'on ne trouve pas de faille... Si il n'y avait que quelques centaines encore... mais là, faut arreter hein ?
De plus, je te rappelle que mozilla est open source, donc ceux qui en ont les compétences peuvent chercher les failles beaucoup plus facilement que celles de IE.
Et puis je doute que chez microsoft, ils aient eu des procédures aussi strict que ça http://standblog.org/blog/2003/10/29/93113130-steve-ballmer-et-la-q(...) pour le developpement.
(arf, j'ai marché dedans je crois non ?)
[^] # Re: Remarque:
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mairie de Paris : Microsoft ou pas ?. Évalué à 2.
60% de serveurs web sous apache ne veut pas dire forcément 60% de serveurs web sous linux.... il y en a beaucoup moins que ça des serveurs linux... Beaucoup d'apache tournent sous windows
voir http://news.netcraft.com(...) (je ne trouve plus le lien des stats par plate-forme...)
[^] # Re: linux n'est pas impacté
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Correction d'un problème de sécurité sous mozilla firefox et thunderbird. Évalué à 4.
la faille a été corrigé moins d'une heure aprés sa publication http://bugzilla.mozilla.org/show_activity.cgi?id=250180(...)
Les compilations des binaires étant faites automatiquement par leur système tinderbox, à partir du cvs, les versions corrigées compilées (officieuses) sont apparues quelques minutes aprés la correction.
> Et surtout, il faudra voir comment les utilisateurs vont être informées et vont télécharger cette nouvelle version
ba là, c'est comme tout.. si l'utilisateur ne se tient pas au courant, il ne pourra pas mettre à jour.. Mais t'inquiete pas, la fondation communique... http://www.mozilla.org/(...)
et les blogs relaient l'info ;-)
# à noter
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Correction d'un problème de sécurité sous mozilla firefox et thunderbird. Évalué à 7.
- soit vous suivez les instructions ici http://mozilla.org/security/shell.html(...)
- soit vous installez l'extension qui va bien : http://update.mozilla.org/extensions/moreinfo.php?id=154(...)
à noter aussi que IE6 est en partie touché par cette faille..
voir la page de test du bug http://www.mccanless.us/mozilla/mozilla_bugs.htm(...)
# un conseil
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Migration MSSQL vers PGSQL :). Évalué à 4.
pose déjà ta question dans le forum, c'est l'endroit le plus aproprié.
[^] # Re: Page "Liens"
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Site de HurdFR de nouveau disponible. Évalué à 4.
browser.block.target_new_window = true
Troll tué.
# c'est inquiétant ces résultats
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 12 ans de conduite et ca s'arrange pas.... Évalué à 7.
Je trouve ça plutôt inquiétant...
[^] # Re: Libertés ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche L'Éducation Nationale veut pouvoir fournir des portables à tous les étudiants. Évalué à -2.
Tu crois que ça va être l'admin système du college (qui n'existe pas dans la majorité des cas) qui va le faire ?
hum...
# faut pas s'en faire
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal TC marche pu ?. Évalué à 2.
[^] # Re: Un lien connexe intéressant
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Ouverture du site gouvernemental Agora. Évalué à 5.
C'est clair. L'un des objectifs de spip-agora : avoir un CMS qui soit accessibles et conformes au standards.
Comme chacun le sait, avec certaines reactions trollesques des dev de spip comme celle ci http://www.uzine.net/article1979.html,(...) il ne faut surtout pas s'etonner du fork. En particulier les dev de spip.
Il est clair qu'ils n'ont pas voulu aller dans le sens des besoins de spip-agora, donc : fork.
Quelque chose de bien naturelle dans les logiciels libres en fait ;-)
[^] # Re: Avant ca..
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal CSS Linux Garden. Évalué à 2.
ah ah ah ah !
mort de rire
Mathieu ?! Tu nous aurais menti ?? Tu serais en fait rester du coté obscure ?
mmm... je vais proposer alors l'effacement de ton nom sur http://openweb.eu.org/openwebgroup/membres/(...)
:-D
[^] # Re: XUL...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les rich clients XAML , XUL, Flash/ActionScript : une bataille gagné d'avance pour Microsoft.. Évalué à 3.
Non, mais c'est un peu énervant d'avoir des gens comme toi qui critique quelque chose sans rien y connaître.
>Au fait, tu fais quoi exactement comme projet avec XUL ?
J'ai fais quelques applis web confidentielle en xul.
sinon matte http://xulfr.org..(...) "LaurentJ" te diras peut être kkchose ;-)
Et si tu es suffisement de temps, tu trouveras mon site avec mon cv..
> J'admets que la méthode semble assez élegante.
;-)
[^] # Re: hum ... XUL, CSS, SVG, ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les rich clients XAML , XUL, Flash/ActionScript : une bataille gagné d'avance pour Microsoft.. Évalué à 2.
mais je n'avais absolument pas le temps de développer plus. 1 heure, c'était court pour montrer toutes ces technos...
# hu ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les rich clients XAML , XUL, Flash/ActionScript : une bataille gagné d'avance pour Microsoft.. Évalué à 3.
d'avoir à réecrire, le code de la logique métier des objets du coté client.
tout simplement parce que la logique metier, elle n'a rien à faire dans la couche "presentation", coté interface quoi...
Faut pas tout mélanger... Si les méthodes de conception en sont arrivé à séparer en couche les différentes parties d'une applis, ce n'est pas pour rien.
Quant à executer du bytecode java provenant du serveur, ça existe déjà depuis des lustres, ça s'appelle des applets. Peut être en étudiant le résultat de l'épopée de cette techno, tu comprendra pourquoi on n'utilise plus du bytecode java coté client.
> La communauté de Mozilla veut faire trop compliqué pour répondre à un besoin qui n'est en soit pas si compliqué que çà.
je te propose de t'informer plus sur le pourquoi du comment, notament, historiquement, pourquoi Mozilla a inventé XUL et co, et pour quel usage...
[^] # Re: XUL...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les rich clients XAML , XUL, Flash/ActionScript : une bataille gagné d'avance pour Microsoft.. Évalué à 4.
Oui, et en utilisant une partie de ton cerveau, tu pourra même te réaliser une petite bibliothèque qui te permettra de faire tout ça en 2 lignes de code. (ou au pire, en récuperer une déjà toute faîte..)
> De même, tu effectuera un traitement similaire pour la réception du retour. Je me trompe ?
non, et alors ?? ça s'appelle faire appel à des services web (tu sais le truc qui te permet justement de tout garder tes objets metiers coté serveur, et de pouvoir les utilisé depuis n'importe où : appli web, client desktop etc...)
> Dans un autre langage, tu effectuera la même opération côté serveur.
euh, excuse moi, mais le serveur il est toujours là pour faire des traitements metier.
Je dirais même que ton appli en xul sera plus performante et le serveur moins surchargé, car il n'a plus à regénérer l'interface graphique d'un formulaire à chaque fois que l'on veut changer un truc dans le formulaire.
Il fait juste les traitements qu'on lui demande de faire au travers de services web.
(Mozilla sait faire du SOAP nativement, donc à priori, il n'y as pas 15000 lignes de code JS à écrire pour faire appel à un web service afin de poster le contenu d'un formulaire et récuperer l'éventuel résultat,dans le cas d'un formulaire de recherche par exemple)
>Dans un formulaire HTML, tu n'as pas besoin d'effectuer la première opération. Elle correspond à la reconstruction de l'interface avec le rechargement de la page.
et tu trouve ça efficace ?
moi non. et pas super friendly pour l'utilisateur.
essaye http://mab.mozdev.org.(...)
exercice : faire la même chose classiquement en HTML/PHP, tout en étant aussi friendly, ergonomique etc... (on comparera le nombre de ligne de code en JS ok ? ;-)
> Si le langage associé à la description de ton interface dans un langage tel que XUL et le même que celui executé du côté serveur. Tu pourrais envisager d'écrire une seul fois l'objet partager entre le serveur et le client rich. Les echanges de données entre les deux parties se ferait simplement par une serialisation et deserialisation de ton objet.
t'es un tueur toi non ? Ta dévise ne serait-elle pas "pourquoi faire simple quand on peut faire compliqué" ?
> L'avantage de Microsoft avec XAML, c'est qu'ils ne se poseront même pas la question vu que tout est déjà integré dans .Net.
Ils ont juste à écrire le browser, la plateform fera déjà le reste !
bien sûr...et la marmotte...
[^] # Re: Petit problème...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les rich clients XAML , XUL, Flash/ActionScript : une bataille gagné d'avance pour Microsoft.. Évalué à 4.
hum...
Si XUL n'est pas si connu, c'est tout simplement à cause de la politique de mozilla.org, nullement le fait que cela ne répondent pas au besoin.
Les developpeurs de mozilla.org n'ont pensé pendant des années qu'à developper XUL uniquement dans l'optique de faire leur browser. Et en aucun cas dans l'optique de pouvoir faire d'autres applis avec.
Cela ne fait que quelques mois qu'ils commencent à comprendre que les technos qu'ils ont développé ont un potentiel énorme, en dehors de leur browser.
> Néanmoins reconnait qu'il y a bcp plus de personne maitrisant Flash et ActionScript que dans les technos de Mozilla.
c'est juste une histoire de marketing.
[^] # Re: hum ... XUL, CSS, SVG, ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les rich clients XAML , XUL, Flash/ActionScript : une bataille gagné d'avance pour Microsoft.. Évalué à 9.
permet moi d'en douter
>Tu pourras faire une interface graphique à peine plus complexe qu'avec du XHTML/CSS/EcmaScript.
ben voyons.
Un menu déroulant par exemple.
En xul : 2-3 balises à ta disposition.
En xhtml : 2-3 balises, + du code javascript dans tout les sens.
Désolé, mais il n'y a pas photo. On peut réaliser des interfaces VRAIMENT complexe avec XUL, sans que ce soit réèllement difficile.
> Mais si tu veux pouvoir réutiliser tes composants afin de les mettre à profit à d'autre endroit d'un projet. Tu ne pourra qu'en acquerant des compétences dans d'autre technologie et la tu te retrouves à te plonger dans la description: XPCOM , XBL, création de XPI.
euh... je ne vois pas ce que viennent faire XPCOM et XPI pour faire des composants graphiques réutilisables.
Dans le cas d'une appli web, tu n'as pas vraiment besoin de XPCOM ou XPI. Les traitements metiers se font toujours coté serveur web, en php java ou autre. Bref, ça ne change pas beaucoup de maintenant. Il y a juste l'interface qui change.
>Sans compter, les problèmes de déploiements de composants XPI du aux différentes versions de Mozilla.
oui mais ça, ça n'a rien à faire dans des applis web.
>A çà, tu rajoutes le développement du coté serveur dans un autre langage et tu te retrouves avec un beau mic-mac.
je ne vois pas en quoi c'est plus micmac que maintenant.
Une appli web actuellement, c'est quoi ?
HTML + CSS + JS + PHP/JAVA/autre
Une appli web en xul, c'est quoi ?
XUL (+XBL) + CSS +JS + PHP/JAVA/autre
où vois-tu que c'est plus le bordel ?
> Ou chaque développeur est irremplaçable car il n'y a que lui qui maitrise une technologies employé dans le projet.
tout développeur web maitrise un minimum HTML, CSS, JS, et PHP/JAVA/autre
Sous pretexte qu'on remplace le HTML par du XUL, il ne saurait plus rien faire ? ne saurait plus faire que du JS ou que du PHP ou... ???
>A çà, tu rajoutes toutes les parties codes qui vont être réecrite plusieurs fois. Par exemple, un objet métier et son comportement une fois en JavaScript côté client , une fois Php ou en Java côte serveur.
Ahh ? parce que pour toi, un objet metier fait parti de l'interface graphique ???? boudiou, tu as des méthodes de travail plutôt bordelique ! je comprend maintenant que tu t'en sort pas avec HTML +CSS +js + php/java/autre tout ensemble !
>ref, tu changes un attribut ou comportement de ton objet métier, tu modifie le projet à 2 endroits différents dans deux langages différents.
pas plus que pour une appli web classique
>De plus, Microsoft, et Macromedia propose un système reposant sur une seul implémentation. J'espère que Mozilla, et Opera s'arrangeront aussi pour avoir qu'une seul implémentation...
Ah ba oui, reposer sur une techno propriétaire, c'est en effet plus facile d'avoir qu'une seule implementation, que quand on essaie de se reposer sur des technos standards, où il faut s'entendre avec tout le monde pour que ça fonctionne...
Oui mais faut voir les résultats aprés...
> Bref du bonheur.
tu l'as dit bouffi. mais renseigne toi un peu plus sur XUL. Je crois qu'il te manque quelques infos pour pouvoir faire une comparaison objective qui ne tourne pas au troll.
[^] # Re: hum ... XUL, CSS, SVG, ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les rich clients XAML , XUL, Flash/ActionScript : une bataille gagné d'avance pour Microsoft.. Évalué à 3.
mince alors... j'avais des VIP et je ne le savais pas :-)
bon, sinon désolé si je t'ai endormi... (jamais facile de toute façon d'assister à une conf aprés déjeuner, et je ne suis pas le genre d'orateur qui sait reveiller les foules )
[^] # Re: Je te comprends ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Petite réflexion sur les standards Web. Évalué à 3.
OH ! Un troll !
arrachage de cheveux quand on débute. (normal, il faut désormais apprendre html et css ! ainsi que les petites astuces pour que ça passe partout... tu parles d'une histoire !)
Mais ensuite, ça passe tout seul quand on commence à maîtriser.
(bref, c'est comme tout hein..)
M'enfin vouloir faire en sorte que ça passe à la fois sous IE4 et sous IE6/moz/truc, faut vraiment être un masochiste et avoir justement du temps à perdre. Parce que c'est vraiment de la perte de temps que de rendre "compatible" un site conçus avec les standards, avec un navigateur qui comprend à peine les standards.. Et c'est d'autant plus de temps de perdu que quasiement plus personne ne l'utilise...
Commencer la compatibilité avec la version 5.0, ça va, mais avec le 4, c'est débile.
(ou alors appliquer une astuce css pour pas que les feuilles de styles s'appliquent pour IE4, et là ça passe super nickel ;-) )