Forums : Extensions

Pour le .exe, je ne peux pas tester, j'ai pas de windows.

Peux tu expliciter plus clairement ton projet ? je ne vois pas trop l'interet du truc.

Il s'agirait de rendre firefox évènementiel dans le sens ou il pourrait communiquer les évènements soulevés dans l'interface ... attention..... au serveur web.....

Le serveur web traite l'évènement et renvoie la mise a jour au client.

L'utilisateur, lui, n'y verrai que du feu.

L'intérêt officiel qui est sensé être apporté c'est que l'application est plus maintenable car tu n'as plus la necessité de coder la prise en compte des évènements dans un autre langage que ton langage principal, je veux parler de celui que tu utilises pour coder ton métier ou les acces a la base de données etc...

Effectivement le projet etant une spécification de fonctionnement évènementiel il peut etre implémenté en n'importe langage, y compris le langage principal de ton application(java, php, dot net ...).

Si cela t'interesse je peux t'envoyer les specs et l'intro au format pdf.

J'espere avoir été clair.

D'autre part, penses-tu toi ou ta boite etre interessé par le projet ?

PS : sinon pour ceux qui veulent tester j'ai eteint mon pc chez moi donc vous aurez une erreur 404 si vous vous connectez avec le "proof of concept" en ce moment. Envoyez moi plutot un mail pour me dire quand vous désirez tester, je lancerai alors mon serveur.

Je n'ai toujours pas compris l'interet de ton extension. Qu'est ce que cela apporte par rapport à la réalisation d'une application web classique en client leger riche tels que décrite sur /wiki/ApplisWeb/Architecture ? Pourquoi une extension alors que l'on peut faire sans ?

D'aprés à ce que j'ai compris de ton projet, cela apporte un gros inconvénient que de déporter la partie évènementielle coté serveur : l'interface est beaucoup moins réactive, la charge serveur plus lourdes, la bande passante augmentée. Tout pour déplaire à un DSI ou aux utilisateurs . Le seul avantage (et encore) c'est de satisfaire le développeur, et uniquement lui. Je me trompe ?

je peux t'envoyer les specs et l'intro au format pdf.

Oui si tu veux, je suis curieux, ça me permettrai de mieux comprendre ce que tu veux faire

penses-tu toi ou ta boite etre interessé par le projet ?

non pas du tout, pas le temps et ce n'est pas notre scope. J'ai assez de projets sur les bras

Je n'ai toujours pas compris l'interet de ton extension

• le code est centralisé = maintenance plus simple/évolutive

• le langage pour le traitement des événements est le meme que le langage utilisé pour les aspects métiers ou les accès bases de données par exemple... : uniformité de l'application et cela diminue le problème des développeurs qui doivent souvent travailler sur des langages différents java/javascript ou php/javascript
• tout le code s'execute sur le serveur : centralisation des déploiements

Ca fait pas mal d'avantages quoi qu'on en dise. Dans l'idée, ca ressemble a du client lourd pour le WEB.

De plus je pense que cette philosophie s'intégrerait parfaitement dans la plateforme firefox avec javascript notamment l'objet XMLHttpRequest, car toutes les données echangées sont bien sur en XML... le pas avec le fonctionnement actuel de firefox est finalement assez mince...

l'interface est beaucoup moins réactive

moins réactives oui mais il reste a prouver que l'utilisateur le remarquera significativement...

la charge serveur plus lourdes, la bande passante augmentée

avec l'évolutions de les bandes passantes et des serveurs il me semble que cette remarque soit a nuancer. De plus les données échangées sont très légères il s'agit d'échanger quelque lignes XML et non pas des pages entieres de données.

Le seul avantage (et encore) c'est de satisfaire le développeur, et uniquement lui. Je me trompe ?

ceci ne peut pas être un avantage en soi, il faut bien sur je suis d'accord avec toi que tout le monde y gagne sinon il n'y a pas d'interet. D'autre part trouves-tu qu'il y a un problème au niveau des développeurs actuellement ? ;-)

Oui si tu veux, je suis curieux, ça me permettrai de mieux comprendre ce que tu veux faire

es-tu interessé ou pas ?? ;-)

non pas du tout, pas le temps et ce n'est pas notre scope. J'ai assez de projets sur les bras

ok je comprend, c'est dommage je pense reellement qu'il y a un potentiel...

Toujours personne interessé pour l'instant.

allé allé motivez-vous ca peut valoir la peine.

Si je trouve une ou deux autres personnes, alors je pourrai commencer des démarches pour trouver un partenaire financier rechercher des aides pour l'innovation etc... Allé un peu de courage ;-)

J'ai fini par trouver une machine windows (ça se fait de plus en plus rare de nos jours... :-D) et à tester ton truc.. Je n'ai pas pu tester grand chose, l'url donnée n'étant pas valide.. Par contre j'ai lu tes specs (pourquoi ne les mets tu pas directemnt sur ton site ?) : je t'apprend donc que tu ne fais effectivement, que réinventer la roue, comme je le disais..

le code est centralisé = maintenance plus simple/évolutive
tout le code s'execute sur le serveur : centralisation des déploiements

Dans toutes applications web, qu'elle repose sur une interface riche (XUL) ou pauvre (html), qu'elle utilise ou non les services web pour dialoguer avec le serveur, et même si une partie (l'interface, le javascript, ou ton langage xml..) s'execute coté client, le code complet reste centralisé sur le serveur. Rien de nouveau donc.

le langage pour le traitement des événements est le meme que le langage utilisé pour les aspects métiers ou les accès bases de données par exemple... : uniformité de l'application et cela diminue le problème des développeurs qui doivent souvent travailler sur des langages différents java/javascript ou php/javascript

En quoi travailler avec plusieurs langages est-il un problème ? Chaque langage est conçu dans un but précis. Aucun ne pretend permettre de tout faire. Chacun ont leur spécialité. Exemples : XUL pour l'interface, javascript pour la logique de l'interface (réaction aux evenements, appels des services web...), CSS pour le design, PHP/JAVA pour les traitements metiers, HTTP/XML pour l'échange des données, XML/SQL pour le stockage etc...

Je trouve au contraire, que cette diversité permet de mieux identifier dans le code source, les différents composants d'une appli. Ce qui est dédié à l'interface, de ce qui est dédié aux traitements metiers -> maintenance plus aisée. Je dirais aussi que ça permet de mieux s'organiser au niveau d'une équipe de développeur. Grâce à l'utilisation de diverses technologique et de la programmation en couche, on peut attribuer à chaque développeur une tâche spécifique : l'un developpera l'interface, l'autre les services web, la coordination de ces services, encore un autre la couche domaine/metier etc..

D'autres parts, ton argument de "vente" c'est il n'y a plus qu'un langage à apprendre, celui utilisé sur le serveur, et la motivation de ton projet repose en partie (cf tes pdfs) sur le fait que les langages actuels utilisés dans les applis web ne sont pas tous standardisés etc..

Tout ceci est completement faux. Il va falloir au developpeur apprendre ton fameux langage XML w-window (donc finalement, un langage de plus), qui plus est n'est pas normalisé... De plus, je te rappelle que le javascript de Mozilla/Firefox, que HTML, CSS et autre XForms &co sont normalisés par le W3C ou l'ECMA..

Donc utiliser du javascript coté client, n'est pas plus mal que d'utiliser ton langage XML. Au moins c'est normalisé, connu, il y a même des interpreteurs javascript libre et dispo en C ou JAVA.

Dans l'idée, ca ressemble a du client lourd pour le WEB.

Exactement. C'est ce que je t'ai expliqué plus haut, que j'explique ici /wiki/ApplisWeb/ (et plus précisement, ici /wiki/ApplisWeb/Architecture, section "Architecture client-serveur "légère"").

D'ailleurs, ce que tu evoques, ce n'est pas du client lourd, mais plutôt du client leger (le navigateur) riche (car utilisant une interface riche, en xul, à l'opposé de l'interface pauvre, en html).

avec l'évolutions de les bandes passantes et des serveurs il me semble que cette remarque soit a nuancer

Je ne suis pas de ton avis. Tout le monde dis ça. Mais que constate -t-on aujourd'hui : il faut sans arrêt upgrader les machines, upgrader les reseaux, parce qu'il y a des développeurs qui pensent comme toi. Heureusement que les developpeurs de linux par exemple ne sont pas comme ça, sinon on ne pourrait plus utiliser de vieux 386/486.

Quand on peut faire plus rapide, plus performant, il faut le faire. Le materiel n'evolue pas aussi vite que le code. Et le materiel, ça coute cher. Et puis ton appli, elle passera peut être avec 10 utilisateurs.. Mais quand la société utilisant ton truc augmentera ses effectifs, ou sera utilisé par une autre boite avec 500 utilisateurs simultanée, que se passera t-il ?

Si dés le départ tu n'as pas un objectif d'optimisation, tôt ou tard (tôt plus que tard d'ailleurs), ton appli arrivera à ses limites. Ou alors, il faut vraiment que ce qui empeche une bonne optimisation, en vaille vraiment la peine. Mais conçernant ton projet, permet moi d'en douter

De plus les données échangées sont très légères il s'agit d'échanger quelque lignes XML et non pas des pages entieres de données.

Je commence à croire que tu n'as pas lu tous les liens que je t'ai donné. Tu es en train de me repeter ;-) Je persiste à croire que ton projet est une réinvention de la roue.

D'autre part trouves-tu qu'il y a un problème au niveau des développeurs actuellement ?

Oui, de plus en plus ont la flemme d'apprendre differents langages, ils veulent tout faire avec une même techno, juste celle qu'ils connaissent, même si elle n'est pas adaptée à ce qu'ils font :-p D'autres encore reinvente la roue sans reèllement innover.

es-tu interessé ou pas ??

À mon avis, si tu veux interresser du monde, il faudrait pouvoir voir du concret. Le concret, ce sont les specs, un vrai document qui explique en détails ce que tu veux faire. En effet, grâce aux specs, les gens seront à même de juger :

• si le projet en vaut la peine selon eux
• si ils en sont capables ou si ils ont suffisement de temps à y consacrer en voyant le travail à réaliser

Mets donc ton pdf quelque part et donne le lien, que chacun puisse juger un peu mieux ce que tu veux faire, et qu'il ne soit pas obligé d'executer un truc .exe pour voir ces pdfs. (tout le monde n'a pas le malheur d'utiliser MS windows)

Si je trouve une ou deux autres personnes, alors je pourrai commencer des démarches pour trouver un partenaire financier rechercher des aides pour l'innovation

encore faut il que ton truc soit vraiment innovant. Pour l'instant, tu ne m'a personnellement pas convaincu de ce coté là. Il existe déjà des projets similaires au tient, bien plus abouti, fournissant même, entre autre des environnements de développements totalement intégré (ex: http://xwidglets.secretgate.com/, et tu en a toute une ribambelle listée ici http://xul.sourceforge.net.

Sinon, comme je le dis, on peut trés bien réaliser une application web avec du XUL et xmlhttprequest, reprenant les mêmes principes que ton projet utilise, sans avoir à installer une extension ou quoique ce soit d'autre. Juste un navigateur.

Tiens d'ailleurs, une chose, réèllement importante, mais que tu n'as pas du tout préciser : c'est un projet sous licence libre ? ou propriétaire ?

Bon courage pour la suite.

Je viens de lire ton mail vite fait et je te répond rapidement pour certaines choses :

J'ai fini par trouver une machine windows (ça se fait de plus en plus rare de nos jours... :-D) et à tester ton truc..

oui je suis tt a fait d'accord, le code est portable (SWT), je n'ai simplement pas eu le temps de faire un fichier d'installation sur les différentes plateformes.

Je n'ai pas pu tester grand chose, l'url donnée n'étant pas valide..

tu as eu une erreur 404 mon serveur tomcat n'etant pas démarré.

(tout le monde n'a pas le malheur d'utiliser MS windows)

Préviens moi par mail si tu veux faire un essai.

Pour les autres points je lis et analyse ton mail ;-)

En quoi travailler avec plusieurs langages est-il un problème ? Chaque langage est conçu dans un but précis

J'ai déjà donné les améliorations que le projet peut apporter :

• code centralisé, le code est uniforme, amélioration des déploiements, possibilité de débugger sur le serveur etc...

La conséquence devrait etre une amélioration substantive de la qualité des applications WEB mais je me répète : en fin de ce message, vous trouverez un lien pour télécharger les spécifications et l'introduction et avoir précisemment le détail de tout ce que peux apporter le projet.

même si une partie (l'interface, le javascript, ou ton langage xml..) s'execute coté client, le code complet reste centralisé sur le serveur. Rien de nouveau donc.

dans mon architecture, il n'existe pas de langage XML. Donc il n'exite pas non plus de langage s'éxécutant sur le client. Meme si par abus de langage j'ai pu l'apeller a tord dans les specs "langages", il s'agit a proprement parler uniquement de données XML. Ces données sont exploitées par le code du navigateur pour faire les bons traitements.

Tout ceci est completement faux. Il va falloir au developpeur apprendre ton fameux langage XML w-window (donc finalement, un langage de plus), qui plus est n'est pas normalisé

Comme je disais pas et pour être plus précis il n'y pas de langage a apprendre uniquement un format XML a connaitre. Ainsi il n'y a rien a normalisé du tout il faut uniquement respecter le format des fichiers XML du projet décrit dans un XFD ou une DTD.

Et puis ton appli, elle passera peut être avec 10 utilisateurs.. Mais quand la société utilisant ton truc augmentera ses effectifs, ou sera utilisé par une autre boite avec 500 utilisateurs simultanée, que se passera t-il ?

Ce qui se passe a chaque fois que l'infrastructure n'est pas correctement dimensionnée mais ca ce n'est pas choquant je ne vois pas en quoi dimensionner l'infracstructure coté serveur en fonction de la charge pose un probleme...

Ce que tu sembles de plus oublier c'est que dans les autres hypotheses on "upgraderait" non plus les serveurs mais le matériel coté poste utilisateur.

C'est donc exactement le meme problème de performance vu du client ou vu du serveur... Ca serait un grossier a priori de penser qu'il vaut mieux décharger le serveur. D'ailleurs une petite remarque pourquoi après tout les deux philosophies ne coéxisteraient-elle pas, sans se manger entre elles...?

il faut sans arrêt upgrader les machines, upgrader les reseaux, parce qu'il y a des développeurs qui pensent comme toi

Voila exactement ce qui se passera aussi au niveau des postes utilisateurs quand on complexifiera les applications en déportant les traitements sur le client au lieu de les laisser sur le serveur....

D'ailleurs ce que tu décris est exactement ce qui se passe au niveau des clients en ce moment...

Oui, de plus en plus ont la flemme d'apprendre differents langages, ils veulent tout faire avec une même techno, juste celle qu'ils connaissent, même si elle n'est pas adaptée à ce qu'ils font :-p

Je ne rentrerais pas dans ce genre de discours pas tres constructif ;-P.

Je tiens à confirmer que XUL est un tres bon langage et je n'ai absolument pas de problemes avec ca. D'ailleurs XUL en tant qu'architecture est très innovant et bien pensée.

encore faut il que ton truc soit vraiment innovant. Pour l'instant, tu ne m'a personnellement pas convaincu de ce coté là. Il existe déjà des projets similaires au tient, bien plus abouti, fournissant même, entre autre des environnements de développements totalement intégré (ex: http://xwidglets.secretgate.com/,

Heu justement xwidglets est le contre-exemple par excellence, il y a du javascript dans des balises XML et qui s'exécute donc coté client, tout ce que mon projet voudrait éviter.

tu en a toute une ribambelle listée ici http://xul.sourceforge.net.

ok j'vais regarder mais si ils font tous comme xwidglets je crains que ce ne convaincra pas... Mais je vais regarder et faire un bilan si qq chose ressemble a ce que je veux faire.

D'autres encore reinvente la roue sans reèllement innover.

Pourtant dans ta remarque suivante, tu as bien l'air de parler de quelque chose qui n'existe pas.

Sinon, comme je le dis, on peut trés bien réaliser une application web avec du XUL et xmlhttprequest, reprenant les mêmes principes que ton projet utilise, sans avoir à installer une extension ou quoique ce soit d'autre. Juste un navigateur.

oui très bien tu as tout dit !!! Tu veux dire qu'on derive firefox pour en faire un autre qui implémente les specs w-windows ? Oui ca c'est une bonne idée, je trouve.

Tiens d'ailleurs, une chose, réèllement importante, mais que tu n'as pas du tout préciser : c'est un projet sous licence libre ? ou propriétaire ?

Je n'ai pas pensé encore a ces aspects car je ne maitrise pas encore tout les tenant et aboutissant d'un tel choix. Cependant je pense très fortement à m'orienter vers du libre, quand j'aurai bien sur trouvé des personnes interessées... ;-)

Bon courage pour la suite.

Merci beaucoup.

Mets donc ton pdf quelque part et donne le lien

oui tout a fait, vous trouverez donc les spécifications et l'introduction à l'url suivante :

ftp://dummy.w-windows.com@w-windows.com le mot de passe est "dummy"

N'hésitez donc pas a me joindre si cela vous interesse, je compte sur vous...

Mouai, bon, j'ai du mal me faire comprendre. En tout cas je ne suis pas d'accord avec toi sur ce que devrait être une bonne architecture client serveur et sur les technologies à utiliser.

dans mon architecture, il n'existe pas de langage XML. Donc il n'exite pas non plus de langage s'éxécutant sur le client. Meme si par abus de langage j'ai pu l'appeller a tord dans les specs "langages", il s'agit a proprement parler uniquement de données XML. Ces données sont exploitées par le code du navigateur pour faire les bons traitements.

ton format XML, il faut tout de même l'apprendre. Ce que je voulais dire, c'est qu'apprendre un langage ou un format XML, c'est kiff kiff, surtout pour un informaticien. Et tes fichiers XML ne vont pas être pondu tout seul ! (ah moins que tu envisages d'implementer un truc miracle ? ). Donc qu'on écrive un truc en XML ou un truc en javascript, ça sera pareil au même, à peu de chose prés la même somme de boulot en définitive. Sauf que toi tu déportes tous les traitements (interface + metier) coté serveur. (tiens, d'ailleurs, j'y pense, ça ne revient pas au principe des applis webs classique HTML ton truc ? HTML ~ ton format XML, et PHP/JAVA, les programmes qui font tout coté client, evenementiel et traitement metier).

Ainsi il n'y a rien a normalisé du tout

hum... XHTML = format XML pour stocker les données d'un document XML. As ton avis, c'est inutile d'avoir des formats standardisés ? Pourquoi crois tu que le W3C, l'OASIS, ou encore l'ECMA existe ? Pourquoi crois tu que certains veulent que XUL soit normalisé ? Pourquoi crois tu que SOAP, RDF, DOCBOOK et plein d'autres formats pour des données industrielles ou autres, sont normalisés ?

La normalisation, c'est utile. vraiment utile. Ça permet justement de vouloir capitaliser sur les connaissances, de permettre aux developpeurs de reutiliser leur compétence d'un projet à un autre. Bref, de ne pas avoir à apprendre un nouveau langage ou format tout les jours, si c'est pour faire finalement à peu prés la même chose.. N'est ce pas d'ailleurs l'argument de ton projet ? Bon ok, tu ne vas pas normaliser toi même ton format XML. Il faut que ce format soit accepté par d'autres implementations. Cependant, si tu veux, et c'est toi même qui le dit, que ton système puisse être independant de tout autre langage (PHP, JAVA etc..), il faut bien qu'il finisse par être normalisé, si tu veux que les differentes implementations soit compatibles entre elles. Avoir une DTD dans un coin ne suffit plus à un moment ou à un autre..

Ensuite, pour moi il n'y a vraiment pas d'inconvénient à faire executer par le client tout ce qui concerne la logique de l'interface (donc ici du javascript, qui est parfait pour cela). Je trouve que répartir les charges entre serveur et clients est une bonne chose.

Je prendrais un exemple assez simple. Imaginons une liste d'information, déjà récupérée via un web service, placée dans un <tree> en XUL, sur plusieurs colonnes. Imaginons que l'on veuille pouvoir trier sur une colonne quand on clic sur l'entête.

Dans ton cas, quand on clique, il faudra envoyer l'évènement sur le serveur, recuperer les données triées (donc requete SQL et tout le bazar), les reintegrer dans le <tree>, et réafficher.

Dans le cas d'un client léger riche, il n'a pas besoin de communiquer avec le serveur pour ça. À priori, il a déjà toutes les données reçu puisqu'elles sont affichées (stockées dans un cache sous forme RDF dans le cas d'une appli XUL). On clique sur la colonne pour trier, les données sont réaffichées triées, sans avoir à communiquer avec le serveur. Cela est fait par l'intermédiaire de quelques lignes javascript, et encore, ici, la fonction tri est déjà implémenté dans le <tree> , il suffit de mettre les bons attributs et de bien faire son <template>. On peut imaginer que pour d'autres cas d'affichage de données, où il est nécessaire d'executer quelques lignes de code javascript, cela va prendre quelques millisecondes de plus pour traiter les données affichées.

Je te laisse deviner, pour une liste de 3000 items par exemple, laquelle des deux solutions est la plus rapide et la plus simple à mettre en oeuvre. Et donc laquelle est la plus confortable pour l'utilisateur et la moins contraignante pour le serveur.

Il peut y avoir 15000 utilisateurs sur le même serveur, il peut y avoir une coupure réseau momentannée, le client léger riche réagira instantanément pour afficher ses données triées selon une colonne. Pas avec ton système, le temps dépendant de la charge serveur, de la complexité de la requête SQL,de la disponibilité réseau etc...

On pourrait multiplier plein d'exemples de ce type.

Je pense que les quelques gouttes de sueur en plus que le développeur devra fournir pour programmer dans 2 langages différents, valent bien les mega octets de bande passante et les heures de charge serveur économisées pour l'entreprise (donc l'argent économisée, surtout si le serveur se trouve à l'autre bout de la france, ce qui arrive frequement dans les grosses boites)

je ne vois pas en quoi dimensionner l'infracstructure coté serveur en fonction de la charge pose un probleme

le coté strictement financier. L'upgrade, ça coute cher. Et tu peux demander à n'importe quel DSI : si il peut faire évoluer ses applications ou ses effectifs, ou installer une nouvelle appli sans avoir à upgrader ou à acheter des nouveaux serveurs ou upgrader ses postes clients, il prefera cette solution. Une architecture logiciel comme la tienne, - et c'est strictement mathematique - s'ecroulera plus vite en terme de charge en fonction du nombre d'utilisateurs et de la complexité de l'interface de l'appli, qu'une architecture comme je préconise, où les charges sont répartis entre les clients et serveurs, chacun faisant ce qu'il a la capacité de faire : le client se charge de l'interface (qu'elle soit installée ou téléchargée au début) et de la logique interface, et le serveur, des traitements métiers et de la transmissions des données.

On pourrait faire l'analogie au déménageur. Seul, il peut porter jusqu'à un certain poid. Si ils sont plusieurs, ensembles ils peuvent porter des objets bien plus lourd. Les limites sont repoussées grâce à cette repartition de charge.

Maintenant, si ton truc est déstinée aux petites applications. Y a pas de souci. Mais si tu comptes en faire un truc plus universel pour grosses et petites applis, là, tu ne prend à mon avis pas la bonne direction.

Voila exactement ce qui se passera aussi au niveau des postes utilisateurs quand on complexifiera les applications en déportant les traitements sur le client au lieu de les laisser sur le serveur..

Si à priori un poste est dimensionné dés le départ pour supporter facilement un firefox par exemple, je ne vois pas en quoi une complexification de l'application va être plus contraignant pour ce poste. Plus de fichiers à télécharger pour l'interface ? plus de services web à appeler ? Oui, mais ça, c'est pas le poste qui va en patir, c'est le serveur. Quelques que soit d'ailleurs la solution (la tienne ou la mienne, mais ce sera pire dans la tienne). Quand à l'affichage de l'interface de l'appli, l'execution du javascript, ça n'est pas un problème. À priori, le javascript est juste là pour faire la glue entre l'interface et les services web ou entre les composants de l'interface. Le risque d'inflation de code javascript sur un clic de bouton est donc vraiment limité. La seule limite à l'évolution, c'est la mémoire, dont l'occupation est directement proportionnel au nombre d'écrans ouvert en même temps. Cependant, si pour utiliser une appli, il faut 10 fenêtre ouvertes en même temps, il y a à mon avis un problème d'ergonomie quelque part ;-)

En résumé, une application peut trés bien se complexifier, et évoluer, sans pour autant que le client en patisse. Il suffit que les devs fassent bien leur boulot en matière d'ergonomie et interface utilisateur. Il restera, selon le cas (le mien ou le tien), juste le problème de réactivité de l'application.

Tu veux dire qu'on derive firefox pour en faire un autre qui implémente les specs w-windows ?

non, je veux dire qu'à mon avis, il n'y a pas besoin de tes specs pour faire la même chose en plus simple et plus performant.

Mais si tu penses le contraire, il n'y a pas de problème

Bon, j'arréte là ma philosophie geekeste