IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Conception Web Discussion :

Jusqu'où ira l'essor de JSON ?


Sujet :

Conception Web

  1. #21
    Expert éminent
    Avatar de berceker united
    Profil pro
    SQL
    Inscrit en
    Février 2005
    Messages
    3 487
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : SQL
    Secteur : Finance

    Informations forums :
    Inscription : Février 2005
    Messages : 3 487
    Points : 6 030
    Points
    6 030
    Par défaut
    Bonjour,

    Comme pour Pignoufy, je découvre JSON ici. Par contre, cette article me fait rappeler à un précédent sujet concernant l'utilisation inadapté/abusif du XML. Pensez-vous que JSON permet justement de réajuster l'utilisation du XML ?
    Mon avatar ? Ce n'est rien, c'est juste la tête que je fais lorsque je vois un code complètement frappa dingue !...

  2. #22
    Membre expérimenté
    Profil pro
    Développeur informatique
    Inscrit en
    Avril 2009
    Messages
    527
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Avril 2009
    Messages : 527
    Points : 1 523
    Points
    1 523
    Par défaut
    Citation Envoyé par berceker united Voir le message
    Bonjour,

    Comme pour Pignoufy, je découvre JSON ici. Par contre, cette article me fait rappeler à un précédent sujet concernant l'utilisation inadapté/abusif du XML. Pensez-vous que JSON permet justement de réajuster l'utilisation du XML ?
    Pour ce qui est des échanges AJAX en tout cas, ça simplifie les choses. En PHP par exemple, on utilise json_encode et json_decode et hop on a nos objets/tableaux prêts pour le javascript côté client (où on utilisera JSON.parse par exemple) ou pour le traitement en php côté serveur.

  3. #23
    Membre actif Avatar de DrHelmut
    Homme Profil pro
    Software craftsman - JS, Java...
    Inscrit en
    Octobre 2005
    Messages
    112
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Software craftsman - JS, Java...
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2005
    Messages : 112
    Points : 215
    Points
    215
    Par défaut
    Bien qu'étant un gros noob n'ayant pas encore eu l'occasion d'implémenter du JSON sur un projet, je suis plutôt d'accord avec celles et ceux qui estiment qu'on ne peut pas vraiment les comparer et qu'ils ont chacun leur champ d'application.

    Je trouve que sur le papier JSON a deux gros défaults :
    - pas lisible facilement par un humain, là ou une structure xml arborescente permet facilement une analyze de flux par exemple. (Et un bon soft sait lire un xml de façon arborescente sans avoir à écrire des tabulations ni des retours chariots dans le fichier ^^)
    - pas de validation du flux ni de typage des données...

    Après, il est clair que pour les webservices, ça ne peut être que plus performant que via SOAP, mais offre-t-il autant de possibilité ?
    Quid d'un envoie/réception de flux binaire avec JSON ??

    Même si c'est parfois un peu lourd, ce qui est bien avec SOAP c'est que le wsdl est auto-suffisant ! J'ai l'impression qu'avec JSON il n'y a pas moyen de connaitre la signature exacte de la méthode apellée, et ça me choque !

  4. #24
    Membre à l'essai
    Homme Profil pro
    Responsable des études
    Inscrit en
    Octobre 2005
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Drôme (Rhône Alpes)

    Informations professionnelles :
    Activité : Responsable des études

    Informations forums :
    Inscription : Octobre 2005
    Messages : 11
    Points : 12
    Points
    12
    Par défaut
    Moi aussi je pense que ça n'a pas la même utilisation.

    Le JSON va très bien pour faire de l'AJAX où les échanges serveur/client doivent être limités en taille. Il est donc très bien pour le développement d'applications d'échange de données. C'est aussi surtout un langage de tâche de fond, et incompréhensible si on n'est pas averti.

    Le XML est pour moi le standard qu'il faut continuer d'utiliser. Il est lu par les applications de bureau (Excel, Calc d'OpenOffice), on peut facilement comprendre la structure et le contenu, il est lisible par les navigateurs, on peut aussi l'interfacer avec des feuilles de style XSL pour en faire une page web. Il possède des librairies capables de développer sur tous les langages facilement, et de plus en plus d'applications de traitement de données l'utilisent comme format d'entrée.

    Et sinon, il y a YAML qui lui aussi se positionne entre les deux. Mais comme il est n'est pas utilisé par le web, on l'oublie...

  5. #25
    Membre émérite

    Profil pro
    Inscrit en
    Février 2005
    Messages
    1 751
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2005
    Messages : 1 751
    Points : 2 368
    Points
    2 368
    Par défaut
    Citation Envoyé par DrHelmut Voir le message
    Même si c'est parfois un peu lourd, ce qui est bien avec SOAP c'est que le wsdl est auto-suffisant ! J'ai l'impression qu'avec JSON il n'y a pas moyen de connaitre la signature exacte de la méthode apellée, et ça me choque !
    Tu ne peux pas comparer XML et SOAP car le niveau d'abstraction est bien différent...
    Pour la même raison, la comparaison entre JSON et SOAP n'est pas possible.

    JSON est un substrat pour des protocoles alternatifs:


  6. #26
    Futur Membre du Club
    Inscrit en
    Juillet 2008
    Messages
    2
    Détails du profil
    Informations forums :
    Inscription : Juillet 2008
    Messages : 2
    Points : 5
    Points
    5
    Par défaut
    Si tous les web-services Soap étaient migrés vers du Restful - Json, l'on pourrait fermer une centrale nucléaire rien qu'en France !

  7. #27
    Membre chevronné Avatar de zeyr2mejetrem
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    Novembre 2010
    Messages
    471
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Responsable de service informatique

    Informations forums :
    Inscription : Novembre 2010
    Messages : 471
    Points : 2 040
    Points
    2 040
    Par défaut
    Citation Envoyé par robynico Voir le message
    Si tous les web-services Soap étaient migrés vers du Restful - Json, l'on pourrait fermer une centrale nucléaire rien qu'en France !
    Si tous les nains de jardin du monde se donnaient la main, les brouettes tomberaient sur le côté.

    Sérieusement, je pense qu'aucun des formats n'est mauvais en soi. L'implémentation qui en est faite dans un contexte donné peut l'être.
    Si tu ne sais pas faire, apprends. Si tu fais, fais bien. Si tu sais bien faire, enseigne.
    Mieux vaut paraître stupide quelques temps que rester stupide toute sa vie.

  8. #28
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut
    Heu le human readable de XML ....
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    <PID>
      <PID.1>1</PID.1>
      <PID.3>
         <CX.1>PATID1234</CX.1>
         <CX.2>5</CX.2>
         <CX.3>M11</CX.3>
         <CX.4><HD.1>ADT1</HD.1></CX.4>
    
         <CX.5>MR</CX.5>
         <CX.6><HD.1>MCM</HD.1></CX.6>
       </PID.3>
    pour moi les deux on leur avantage et les deux on des domaines d'usage de prédilection.

    Mais cela n'empêche pas de se poser la question du choix
    car contrairement à ce qui a été dit JSON est lui aussi tout comme XML un format validable et instrumentable.

    on a donc an JSON des capacités comparable schémas RPC WS etc.

    ce qui les différencie profondément c'est l'outillage JSON plus jeune est moins bien outillé et surtout pas complètement normalisé pour beaucoup de chose.

    reste donc à savoir ce que l'on veut en faire. si je prends quelques exemple ou le réflexe du développer java sera de choisir XML se poser la question peut ouvrir des horizons.

    par exemple je croise souvent dans des appli java des mécanisme de sérialisation xml d'objet soit pour se les échanger soit pour les conserver dans des fichiers.
    cela demande un sérialiseur et un parser qui accepte un schéma et c'est tout chose qu'on a à l'identique avec JSON
    oui la techno sur se point est nouvelle mais elle offre des avantage non négligeable à surveiller donc.

    autre exemple que j'ai croisé récemment des fichier de conf dans une appli C++ qui étaient autre fois en xml et aujourd'hui en Json. avantage léger facile à lire et à éditer structuré évolutif

    maintenant je dois reconnaître à xml sa maturité et dans de très nombreux cas Il a fait ses preuves.
    et je l'utilise énormément.

    Je pense que leurs domaines de prédilection sont distinct mais il y a des zone de recouvrement.

    les comparer et une bonne chose et continuer à le faire aussi.

    J'espère que JSON gardera son approche très pragmatique.

    A+JYT

  9. #29
    Nouveau membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Avril 2011
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Avril 2011
    Messages : 8
    Points : 38
    Points
    38
    Par défaut
    Ayant pas mal utilisé les deux, je ne peux que confirmer ce qui a été déjà été dit : utilisé JSON plutôt que XML, ou l'inverse, dépend de ce qu'on a besoin et du contexte dans lequel on se trouve.

    Par contre pour ceux qui veulent vraiment de la légèreté a l'extrême il existe un autre format inspiré du XML mais linéaire dans l'écriture et dans la conversion: SimBa.

    On y perd la possibilité d'arborescence mais on y gagne en efficacité de traitement.

  10. #30
    Expert confirmé
    Avatar de popo
    Homme Profil pro
    Analyste programmeur Delphi / C#
    Inscrit en
    Mars 2005
    Messages
    2 654
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Analyste programmeur Delphi / C#
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2005
    Messages : 2 654
    Points : 5 209
    Points
    5 209
    Par défaut
    Personnellement, je ne connais pas non plus JSON mais quand je lis ce que me renvoie Google sur le sujet, je remarque un sérieux désavantage par rapport à XML : Il ne convient pas pour des ressource de taille importante !

    Et puis si JSON devient plus populaire que XML, j'aimerai pas être à la place de microsoft. Pour rappel, les fichiers de microsoft office sont en réalité des fichiers XML. En renommant un fichier docx en zip et en regardant à l'intérieur de l'archive on s'en aperçoit très bien.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    <PID>
      <PID.1>1</PID.1>
      <PID.3>
         <CX.1>PATID1234</CX.1>
         <CX.2>5</CX.2>
         <CX.3>M11</CX.3>
         <CX.4><HD.1>ADT1</HD.1></CX.4>
    
         <CX.5>MR</CX.5>
         <CX.6><HD.1>MCM</HD.1></CX.6>
       </PID.3>
    OK, c'est pas très lisible mais je serais curieux de voir ce que ça donnerai en JSON. Pas sur que ce soit plus lisible !

  11. #31
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 547
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 547
    Points : 21 602
    Points
    21 602
    Par défaut
    Citation Envoyé par marts Voir le message
    A mon avis, rien de ce que permet le XML n'est impossible avec JSON.
    Ce n'est pas une question d'avis, tu te trompes.

    - JSON ne peut pas gérer d'organisation en flux, comme le HTML, le DocBook, et certains besoins d'Atom et RSS (qui ne sont jamais utilisés d'accord, mais c'est simplement parce qu'aucun informaticien influençant ces utilsiations ne se donne la peine de comprendre.)

    - JSON n'est pas extensible, sauf à obliger le concepteur des formats de données à prévoir pour extension future, ce qui n'est pas impossible, juste rendu trop compliqué par le fait qu'il ne sert absolument pas à ça.

    On pourrait aussi ajouter que JSON n'a pas de truc comme les entity references ni les character references ni les valeurs par défaut, mais bon, c'est pas des trucs que j'aime beaucoup personnellement.

    Enfin, bien que ça ne soit pas infaisable sur le principe, par nature JSON est un très mauvais candidat pour des choses comme le XML Transform et le XML Process. Pas assez expressif, pas assez extensible, matchers et selectors trop naïfs.
    On va me dire que ce n'est pas indispensable, mais les cas ne manquent pas où c'est mieux qu'autre chose. XML le peut, JSON ne le peut pas.

    Citation Envoyé par sekaijin Voir le message
    Heu le human readable de XML ....
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    <PID>
      <PID.1>1</PID.1>
      <PID.3>
         <CX.1>PATID1234</CX.1>
         <CX.2>5</CX.2>
         <CX.3>M11</CX.3>
         <CX.4><HD.1>ADT1</HD.1></CX.4>
    
         <CX.5>MR</CX.5>
         <CX.6><HD.1>MCM</HD.1></CX.6>
       </PID.3>
    On n'a pas dit que XML a le pouvoir d'obliger à faire du lisible, les gens suffisamment déterminés à produire de l'illisible.

    Simplement qu'il y encourage. (Encore que la mode d'avoir soixante namespaces différents dans un même document n'aille pas vraiment en ce sens, j'en conviens.)
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  12. #32
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut
    Citation Envoyé par popo Voir le message
    Personnellement, je ne connais pas non plus JSON mais quand je lis ce que me renvoie Google sur le sujet, je remarque un sérieux désavantage par rapport à XML : Il ne convient pas pour des ressource de taille importante !
    heu 2Go de données dans un fichier JSON ...
    T'es sur de ce que tu avance ?
    Je ne connais aucune limitation en taille à JSON
    la seule que je connaisse n'est pas du à JSON outils tout comme avec XML si tu utilise DOM il te faut mettre les objets en mémoire et tu en deviens dépendant. Par contre on ne trouve quasiment pas de parser type SAX (de xml) c'est à dire au fil de l'eau. mais aucun limitation dans le format si ce n'est la taille des supports.

    Citation Envoyé par popo Voir le message
    Et puis si JSON devient plus populaire que XML, j'aimerai pas être à la place de microsoft. Pour rappel, les fichiers de microsoft office sont en réalité des fichiers XML. En renommant un fichier docx en zip et en regardant à l'intérieur de l'archive on s'en aperçoit très bien.
    je ne vois pas en quoi cela remets en cause ce choix XML est un bon choix et même si JSON devient populaire il le restera.

    Citation Envoyé par thelvin Voir le message
    - JSON ne peut pas gérer d'organisation en flux, comme le HTML, le DocBook, et certains besoins d'Atom et RSS (qui ne sont jamais utilisés d'accord, mais c'est simplement parce qu'aucun informaticien influençant ces utilsiations ne se donne la peine de comprendre.)
    Là j'avoue ne pas comprendre. je ne vois aucune raison qui empêche d'utiliser JSON à la place de ces flux c'est même se que je fais je n'utilise plus HTML mais JSON est mon moteur de rendu lit des flux JSON bien plus concis et léger.

    Citation Envoyé par thelvin Voir le message
    - JSON n'est pas extensible, sauf à obliger le concepteur des formats de données à prévoir pour extension future, ce qui n'est pas impossible, juste rendu trop compliqué par le fait qu'il ne sert absolument pas à ça.
    Là encore je ne comprends pas. XML c'est des symboles <> = " organisé et des string rien de plus XML n'est pas plus extensible que JSON. si tu entant par extensible qu'on peut mettre dans un XML la balise de son choix, il en va de même en JSON ou tu peux ajouter le membre de ton choix. si tu entends par là qu'un peut inclure dans XML d'autre XML c'est pareil en JSON. la seule différence entre les deux c'est qu'en XML tu a une norme (deux en fait) pour typer plus fortement ton XML.

    Citation Envoyé par thelvin Voir le message
    On pourrait aussi ajouter que JSON n'a pas de truc comme les entity references ni les character references ni les valeurs par défaut, mais bon, c'est pas des trucs que j'aime beaucoup personnellement.
    Les entity sont un pi aller créer pour XML à fin de pouvoir inclure les éléments non supporté par le flux. le seul qu'on ne peut pas utiliser en JSON est " pour cela on a été obligé d'introduire \ du coup pour mettre \ il faut mettre \\ à quoi servent les entity dans un pareil cas ?
    pour les référence c'est effectivement un choix de JSON de ne pas mettre utiliser les références JS dans un flux
    mais XML fait de même. je ne peux pas écrire
    Code xml : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    <user>
      <name>Dupond</name>
      <id>user.name</id>
    </user>
    pour désigner dans la valeur de mon id l'élément name de user user.name ou tout autre forme n'est qu'une chaîne de caractère et non une référence. avec XML je vais pouvoir créer une string qui est le chemin vers l'élément de mon choix.
    Code xml : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    <user>
      <name>Dupond</name>
      <id>/user/name</id>
    </user>
    XML n'interprétera l'élément id que comme une chaîne. il faudra ajouter une passe supplémentaire d'interprétation XPATH pour résoudre les références et obtenir Dupond dans le champs id. avec JSON on est exactement dans la même situation.
    Code javascript : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    "user":{
      "name" :"Dupond",
      "id":"user.name"
    }
    JSON fera de l'élément id une string contenant le chemin et il faudra une passe d'interprétation de cette chaîne pour obtenir Dupond
    la différence entre JSON est XML sur ce point est encore une fois que la façon de décrire le chemin est normalisé. en JSON on utilise soit la notation pointé de javascript soit les sélecteurs CSS mais rien de normalisé.

    Citation Envoyé par thelvin Voir le message
    Enfin, bien que ça ne soit pas infaisable sur le principe, par nature JSON est un très mauvais candidat pour des choses comme le XML Transform et le XML Process. Pas assez expressif, pas assez extensible, matchers et selectors trop naïfs.
    On va me dire que ce n'est pas indispensable, mais les cas ne manquent pas où c'est mieux qu'autre chose. XML le peut, JSON ne le peut pas.
    La encore tu te trompe lourdement. XML ne permet rien de plus que JSON Les outils XML sont disponible et normalisé ceux de JSON non. encore une fois XML n'est que format autour de lui gravitent des normes et des outils les implémentant. pour XSLT par exemple rien de plus simple à faire en JSON t fais un JSON qui définit le pattern en utilisant la syntaxe sélecteurs css3 et le résultat à obtenir en JSON le moteur s'écrit en quelques lignes de JS.
    Mas question est simplement pourquoi le faire lorsqu'avec XML on a déjà les outils. il faut savoir être pragmatique et évaluer l'usage avant le format de support. je pense que des moteurs de transformations arriverons dans le monde JSON que si dans l'ensembles des point à évaluer qui font qu'on choisit se format seul ou persque la transformation est absente. si dans ton dev tu fait deux colonne et pour chaque critères tu mets des points à XML ou a JSON et qu'au final tu as 80% pour JSON et qu'il te manque une fonctionnalité dans JSON tu va l'implémenter. et si tu obtients 80 en faveur de XML et qu'il ne manque une fonctionnalité supporté par JSON tu vas aussi l'implémenter en XML. ça ne change rien.

    Citation Envoyé par thelvin Voir le message
    On n'a pas dit que XML a le pouvoir d'obliger à faire du lisible, les gens suffisamment déterminés à produire de l'illisible.

    Simplement qu'il y encourage. (Encore que la mode d'avoir soixante namespaces différents dans un même document n'aille pas vraiment en ce sens, j'en conviens.)
    C'était une boutade pour l'argument sur la lisibilité. pour moi XML dès sa définition à voulu pousser vers le "Human Readable" mais nous sommes tous face à des choix et il arrive souvent que le meilleur choix même en XML ne soit pas "Human Readble". face à ça JSON à pour sa part cherché à sa naissance à être "Machine Readable" mais transportable en string. et nous sommes ainsi fait lorsque nous choisissons des nom nous les choisissons de préférence lisible par nous. du coup JSON à parcouru le chemin inverse.
    Au final je dis que mettre dans la balance lorsqu'on doit choisir entre JSON et XML le fait que XML est "Human Readable" je réponds que ce n'est pas recevable.

    pour moi il existe des point bien plus fondamentaux dans les différence entre XML et JSON si je dois mixer deux structures de données en XML je peux utiliser les namespaces et la norme comme les outils me garantissent une claire distinction. je n'ai rien de tel en JSON ou par définition de base tout est faiblement typé. se sera à moi développeur de garantir cette distinction.
    ce n'est pas impossible ce n'est pas difficile est juste à faire.
    il existe des contextes d'utilisation où la distinction entre attribut et élément est un plus important. (je ne connais pas de cas où on ne peut s'en passer
    uniquement des cas ou ça rends les chose beaucoup plus claires et faciles) dans ces cas là XML m'offre cette distinction alors que JSON non. là encore ce n'est pas insurmontable, ce n'est pas difficile mais c'est à moi développer de le faire.

    A+JYT

Discussions similaires

  1. Réduisez jusqu'a plus de 65% la taille de vos exécutables
    Par DjmSoftware dans le forum C++Builder
    Réponses: 33
    Dernier message: 01/04/2012, 22h56
  2. [OLE Excel] Aller jusqu'à la dernière cellule rempli
    Par JBrek dans le forum API, COM et SDKs
    Réponses: 9
    Dernier message: 07/08/2009, 20h21
  3. [CSS][Débutant]Alonger un bloc div jusqu'en bas de la page
    Par Thomzz dans le forum Mise en page CSS
    Réponses: 2
    Dernier message: 07/09/2005, 23h58
  4. Un "tant que" ou "jusqu'a" en SQL ?
    Par vdbadr dans le forum Langage SQL
    Réponses: 10
    Dernier message: 19/04/2005, 21h14
  5. forcer une fenetre à etre au premier plan jusqu'a ...
    Par peppena dans le forum Agents de placement/Fenêtres
    Réponses: 3
    Dernier message: 22/12/2003, 17h14

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo