ragoutoutou a écrit 1515 commentaires

je ne sais pas où tu as lu ça, mais je pense que c'est faux.

c'était sur le site du WHATWG, mais ça a été retiré... on en trouve encore des traces dans l'interview de l'équipe xhtml5 sur le site xhtml.com

D'ailleurs, ils disent dans l'interview qu'ils ont décidé de faire la norme x car ils savaient que la demande était trop grande et ils préféraient mettre les choses au net eux-mêmes même si ça ne leur plaisait pas...

Tu as vu la tête de XHTML 2 ? compatible avec rien du tout.

Ben oui, mais il faut dire que le boycott de xhtml 1 par microsoft n'a pas aidé les développeurs à se familiariser avec les avantages du xhtml...

assurément non : pas d'élement media évolué

Non, mais les balises media sont des formalisations redondantes (et un peu inutiles) par rapport à l'usage d'éléments (qui dans xhtml2 peuvent servir tant à l'image qu'au son, ou qu'à la vidéo)

Autre chose : super le remplacement des balises de formulaires par XForms en XHTML2... mais seulement pour les nerds.

Xforms est une manière bien plus élégante de créer des formulaires, et gère des éléments de validation, ce qui réduit le besoin de javascript.

Déjà quand on voit comment sont gérer les balises pour les formulaires ultra simple de HTML4, alors XForms...

Ne faisons pas évoluer les standards parceque les gens codent déjà comme des porcs, c'est donc ça l'argument vendeur pour le html5?
Ian Hickson, l'a dit ouvertement, il veut juste améliorer les possibilités du html4, apporter des quickfix à quelques petits éléments, mais préfère perpétuer le mauvais design de HTML que de mettre une révolution en place...

En tout cas, avec le html5 (et le fait que la partie xml est découragée par les auteurs de ce truc), on ne risque pas de voir de grosse amélioration dans la qualité des pages web...

Je précise, quand je dis :"Oui... il propose une stagnation par rapport au xhtml 1.1 ... par rapport à la refonte du xhtml2, c'est une toute petite évolution."

Je veux dire que ça ne représente rien, que c'est une régression par rapport à la refonte du xhtml2... pas que ça représente une évolution par rapport au xhtml2...

ma phrase prête à confusion.

euh... tu as regardé ce que proposait (x)html 5 ?

Oui... il propose une stagnation par rapport au xhtml 1.1 ... par rapport à la refonte du xhtml2, c'est une toute petite évolution.

XBL2? C'est très bien... mais microsoft va t'il le supporter? Combien de temps avant qu'on ait la version finale w3c?

HTML5 n'est qu'une brique pour les applications riches.

Disons surtout un marche pied dont on peut se passer dans le cadre d'applications riches... Quand tu fais une application XUL, tu utilises encore beaucoup de xhtml?

enfin, ça, ça ne marche vraiment qu'avec des navigateurs supportant réellement le xhtml... donc pas avec I.E., par exemple...

En passant à (x)html5 plutôt qu'à xhtml2, on a en tout cas raté une belle occasion d'évolution... s'enterrer dans les vieux standards moches du web des années 90 ne va pas aider le web à survivre aux technologies proprio comme silverlight et flash. On est occupé à tourner le dos aux applications riches.

Vu la mode ça doit être

"Shadocks, la comédie musicale" par Luc Palmondon et Fatal Bazooka...

bof pas vraiment d'accord. A mon humble avis, la logique devrait être que la gestion d'un éventuel proxy soit faite par l'OS, pas par l'appli.

A mon humble avis, une application qui se prétend "pour l'entreprise", à fortiori dans un contexte où la confidentialité du réseau est importante, et qui n'offre pas de support proxy mais prétend se connecter au web est en tort.

Maintenant, on peut s'amuser à mettre un proxy local transparent qui fait la redirection vers le proxy de l'entreprise, mais ça reste bien lourd pour quelques lignes de code que des développeurs ont eu la flemme d'écrire.

Le reste du débat était par rapport à cette considération étrange et déconnectée de la réalité des entreprises qu'un bon proxy est forcément transparent.

Ah, c'est clair, c'est important de pointer qu'il y a des outils reformulant les pages pour les malvoyants, mais s'il y a moyen de faire les choses correctement dès le début et ne nécessitant pas de soft supplémentaire, je préfère y passer un peu de temps plutôt que de devoir ensuite réintégrer une logique supplémentaire dans mes pages, au risque d'oublier des éléments.

Et si il est bon, il est en plus transparent pour le reste de l'infrastructure : il ne nécessite pas de modification des logiciels utilisés par tout le monde au quotidien.

Si les logiciels qui ont besoin d'accéder à Internet sont bons, ils prennent en compte la réalité du proxy et permettent d'être configurés correctement. Le proxy n'est pas une invention qui date d'hier, c'est assez petit que de blâmer son existence pour exonérer la paresse de certains développeurs.

On a pas la meme définition de *bon* proxy.
Le fait de mettre un proxy transparent ou non est généralement plus lié à des questions de sécurité, de politique d'entreprise, de topologie réseau qu'à une question de compétence d'administrateur... la difficulté technique de la chose est peu importante comparée aux impératifs ci dessus.

mais si vous êtes admin réseau et que vous avez des problèmes, ne le prennez pas mal : y'a pas de honte à ne pas être le plus fort en tout :-D

Comme je l'ai dit, ce n'est pas un problème purement technique, mais bon, il faut avoir travaillé dans une entreprise avec un réseau et une sécurité un peu réfléchis pour s'en rendre compte.

Alors, évidemment qu'il faut s'en rapprocher, je ne les rejette pas ! Mais on peut faire un site standard à base de tableaux ! On peut faire un site standard avec des <br> et des <font> !

Le défaut du site à base de tableaux, c'est que ça peut devenir assez vite effroyable à naviguer avec une tablette braille...

Un des gros problèmes de nombreux web designers c'est qu'ils ne connaissent pas assez de malvoyants.

Un bon site web au niveau accessibilité est un site web qui, quand on retire les stylesheets, s'affiche comme un document texte peu ou pas formaté... et ce n'est pas si difficile à obtenir (et pour un web designer pro, acquérir la compétence pour le faire n'est jamais chose perdue)

Non, un bon proxy est un proxy qui fait son boulot de proxy efficacement, c'est tout... la transparence peut être désirable dans certains cas, mais ce n'est pas spécialement un élément de mesure de qualité.

Dans certaines entreprises, on peut souhaiter avoir un proxy non transparent faisant accéder au web seulement les utilisateurs authentifiés, par exemple... On peut aussi avoir envie de définir plusieurs proxys différents avec des stratégies de sécurité/stockage différentes selon la classe d'utilisateur,...

Quelques questions...

contexte Intranet? Internet?

Clientless?

Si intranet, quel est la gestion d'identité/authentication standard (AD/LDAP/KRB5/...) ?

SSH est-il disponible?

Pourquoi ne pas considérer le développement d'une petite interface web en php?

Allez, à la poubelle HTML, HTTP, TCPI/IP!

On en est pas loin, avec la montée de flash, silverlight et le boycott de xhtml par Microsoft. Les standards du web sont dans le fossé, pour le moment l'industrie se traine à essayer de valider un standard bâtard vestige du web des années 90...

Le HTML5 est une perte de temps, il aurait fallu aller vers le XHTML2, qui lui est plus structuré, mieux formalisé et plus adapté aux besoins de modularité des applications riches. Le HTML5 va juste mener à un constat d'échec sur l'évolution des standards du web face aux technologies riches et propriétaires.

D'ailleurs Microsoft, après avoir poussé vers le HTML5 se rebiffe et parle maintenant de modularité alors qu'il reprochait la modularité du xhtml2.

NIS est une vielle techno mais elle est simple à mettre en oeuvre.

Et impropre à un usage en entreprise pour des questions de sécurité...

NIS? il y en a qui utilisent encore cette crasse???

Bon... blague à part, il faudrait déjà si c'est pour faire du actif/actif, ou du actif/passif... dans le second cas, la réplication bête et méchante est ce qu'il y a de plus simple...

dans le premier, il faudrait déjà savoir quelles sont les applications qui tournent dessus pour définir une politique de clustering.

Ces beaux logiciels vont-ils avoir raison des pilotes graphiques libres en forçant l'utilisation de blobs proprios supportant une chaine HDCP ?

Personnellement, je crains que l'avènement de ce genre de logiciels sous linux représente une menace contre les pilotes libres s'ils rencontrent une adhésion massive.

Faut-il encore le rappeler que tarlouzes comme Novell, IBM, NEC, Philips, Red Hat et Sony se sont alliés en fournissant chaque leurs armes (brevets) pour protéger des logiciels libres comme Linux ou Mono ?

Oui, c'est toujours intéressant à rappeler, je pense même que c'est un élément majeur à mettre en avant qui permettrait de montrer qu'il y a effectivement une forme d'assurance sur Mono dépassant potentiellement le cadre de l'accord de Novell ou de l'ECMA...

Et quand Microsoft le fait, tout le monde gueule en s'improvisant juriste et en criant au loup parcque y'a sûrement un piège :
http://www.microsoft.com/interop/osp/default.mspx

D'un autre côté, dans cette liste, on retrouve aussi l'IP v6, et un paquet d'éléments arrachés par la contrainte par la commission européenne ...

Parcque Linux est un concurrent ? Parcque les acteurs du libre ont autant d'armes pointées dans l'autre sens et que la plupart des accords sont bidirectionnels ?

Tu trouves donc normal donc le fait que Microsoft essaye de se placer comme garde barrière devant GNU/Linux et force les distributeurs à négocier son autorisation pour avoir accès aux libertés du logiciel libre? Et tu voudrais ensuite nous dire d'avancer en terrain miné?

pourquoi mono ? c'est pas spécifique à mono ! c'est tout linux qui est dans la même position vis-à-vis de Microsoft !

Et c'est une raison pour augmenter l'ampleur du risque?

Le fait est que dans le cas de linux, lorsqu'il a été demandé à Microsoft de fournir la liste des brevets supposés violés, ce dernier a préféré continuer à gueuler et à menacer comme si de rien n'était, ce qui tend à indiquer que son histoire ne tient pas sur des bases très solides (le risque est grand de voir des universités se lancer dans un concours d'invalidation de brevets dès que la liste serait disponible), mais ça a suffi à faire peur à quelques entreprises qui ont demandé à Microsoft la permission de continuer à distribuer du linux...

Pour .Net, Microsoft a pour le moment besoin de se faire des parts de marché, quitte à déborder sur le monde libre. Toutefois, Microsoft ne s'implique pas dans le développement de Mono ni ne donne une autorisation explicite à tous d'utiliser les technologies non-ecma. Une fois .Net adopté massivement, Microsoft pourrait faire valoir ses droits et exiger le retrait de technologies dont les applications p

Microsoft garde son fusil chargé et se réserve le droit de tirer quand bon lui semble, c'est suffisant pour se méfier de ses intention. Si par contre il déposait les armes, on pourrait avancer plus sereinement avec mono.

Au rythme où les mentalités changent (et où les têtes pensantes sont remplacées) chez eux, Windows sera libéré dans cinq ans...

Bon, là on voit bien que tu n'es pas bien ancré dans la réalité...

Tout ce que vous cherchez à faire, c'est dénigrer le projet parce que y'a du MS derrière (et encore, indirectement).

Oui, on est que des méchants qui aiment pas Microsoft et n'ont pas de vrais arguments...

arrêtez un peu de convaincre ceux qui l'utilisent et développent avec qu'ils sont des sous-merdes parce qu'ils favorisent l'empire du mal.

Ah oui, on souligne le fait que la problématique des brevets n'est pas mise à plat, donc on traite les développeurs de mono de sous-merdes... c'est logique... et tu programmes sinon?

Pour ta gouverne, de nombreux grands acteurs du marché ont signalé officiellement, en dehors de toute contrainte normative, qu'ils octroyaient des licences perpétuelle et inaliénable à leurs brevets sur certaines technologies pour que les logiciels libres puissent les intégrer. Microsoft ne l'a pas fait, en dehors de ce qui est passé en norme ECMA il n'y a aucune base légale pour ce qui est intégré à Mono, pourquoi à ton avis? Pourquoi Microsoft a t'il décidé de garder une arme chargée braquée sur la communauté libre? Pourquoi Microsoft tient-il à faire signer des accords sur ses brevets aux entreprises qui veulent utiliser ou distribuer linux? Pourquoi Mono est-il un projet à peine reconnu par Microsoft, alors que ce dernier pourrait activement le supporter?

On peut tout de même se poser la question si Microsoft n'essaye pas simplement d'ouvrir temporairement, sans se mouiller, .Net au monde libre tout en gardant le bouton à portée de main pour sonner la fin de la récré une fois ses objectifs de parts de marché atteints.

Si Microsoft daignait donner des signaux forts d'engagement ferme dans une politique d'accès à ses brevets pour tous les utilisateurs de mono (et pas seulement ceux couverts par l'accord avec novell), je pense qu'il n'y aurait plus de quoi autant s'inquiéter.

le principe du champ de mine, c'est qu'on ne voit pas immédiatement où elles sont... et quand on en a trouvé une, il est souvent trop tard...

Quand on voit l'attitude de Microsoft face à Novell, les accords, le fait que Novell ait demandé une assurance de Microsoft de ne pas se faire attaquer pour Mono, on peut se méfier...

Et quand on voit des brevets déposés sur l'utilisation des windows forms (USPTO 20060282817), on se dit qu'il doit y avoir des tas de brevets sur des points clefs des winforms qui trainent ici et là...

Microsoft ne va tout de même pas commencer à faire peur aux développeurs mono alors que ceux-ci rassemblent un maximum de monde à la lisière de la belle clairière à la terre fraichement retournée...

Ben justement, Mono 2.0 supporte officiellement les Windows.Forms de manière complète.

Certes, mais Windows.Forms ne fait pas partie des normes ECMA, font l'objet de brevets, et seuls Novell et ses clients sont autorisés à les utiliser dans Mono ...

Redistribuer une implémentation des WinForms (et quelques autres technologies du stack .Net) sans accord préalable avec Microsoft présente un risque juridique non négligeable.

Mono pourrait bien se transformer en une marche forcée à travers un champ de mines.

il y a régulièrement des benchmarks publiés sur les perfs mono comparées aux perfs .Net, rien de neuf à ce sujet, les dev mono ne vont même pas contester, et ils avancent bien sur le sujet... question maturité, en tout cas, il vaut mieux encore attendre.

Pour la compatibilité, en dehors du fait que mono a une bonne guerre de retard sur .Net, on peut pointer du doigt les pratiques des développeurs d'applications en environnement .Net qui sont beaucoup moins soucieux des problèmes de portabilité que leurs contreparties travaillant sous mono... Microsoft n'encourage pas assez la portabilité et .Net permet trop d'abus.

Dans l'ensemble, il suffit d'analyser avec MoMA (Mono Migration Analyser) des applications .Net populaires pour se rendre compte que la compatibilité n'est pas encore au rendez-vous et que mono ne peut se substituer à .Net comme environnement runtime, à fortiori en milieu professionnel où il faut héberger des applications tierces.

Pour IBM, oui, par contre Sun, d'expérience, je peux dire qu'ils ne sont vraiment pas doués pour la vente... ils sont focalisés sur le hardware et ratent souvent de belles opportunités sur le soft, il faut parfois expliquer à leurs commerciaux des choses comme "vous savez, il y a six ans, vous avez acheté la société x qui faisait le logiciel z, et nous aimerions acheter des licences"...

En tout cas, rien de comparable chez Sun à la machine de guerre commerciale de Microsoft.

Microsoft pousse derrière... ils ont les moyen de trouver des Daltons pour creuser des tunnels avec une spatule...