Journal Projet Badnik, partie 2 : GameData et appel à contribution

Posté par (page perso) . Licence CC by-sa
11
11
nov.
2013

Sommaire

Trois mois plus tard

Peut-être vous rappelez vous de mon article sur la préservation du jeu vidéo qui a précédé la naissance du projet Badnik que je vous ai présenté fin juillet dernier.

Icône de l'application

Et bien le projet a avancé tant bien que mal cet été :

  • il a été décidé que Badnik serait le nom du projet, mais ne sera pas celui des logiciels produits ;
  • le frontend a eu droit à une icône plus personnalisée ;
  • le backend a été porté vers Vala, mais dépend encore de GTK ;
  • le frontend en GTK 3 et Python 3 a été amélioré, mais est destiné à disparaître (changement de langage ou réécriture) ;
  • le build system n'est pas au mieux de sa forme (je ne parle malheureusement que le Makefile, si quelqu'un a des connaissance en Automake je suis preneur) ;
  • la dépendance floue du frontend vers libgd distribué par GNOME Documents est toujours là, mais ce dernier étant destiné à disparaître ce n'est pas si dramatique ;
  • le .vapi d'une des bibliothèques que j'utilise (libgda) est assez bancal, je ferais bien de la remplacer par sqlite3 directement ;

Si tout ça n'est pas forcément merveilleux, ce n'est rien à côté du problème auquel j'ai été confronté :
un des points forts de mon application, à savoir sa recherche et son affichage de métadonnées sur les jeux de votre bibliothèque, repose sur un système très bancal.
Le programme analyse des sites Web spécialisés, et s'il rendent parfois des résultats plutôt bons, ils étaient généralement trop lents mais surtout ne marchaient pas correctement pour tous les jeux : on peut ne pas trouver les données souhaitées alors que le site les contient ou, pire encore, avoir des données ne correspondant pas du tout au jeu ! De plus une connexion à internet est nécessaire et les recherches sont plutôt lentes.

Ce problème me semblant prioritaire, j'ai récemment réfléchit au sous projet GameData.

GameData

Si emmener mon programme vers les métadonnées ne marche pas, alors il me faut faire venir les métadonnées vers mon programme !
Il existe des tonnes de sites référençant des jeux vidéo mais pratiquement aucun n'est réellement exploitable, il me fallait donc une base de métadonnées de jeux facilement exploitables par un programme, et si elle pouvait être embarquée avec le logiciel ça ne serait que mieux !

Richard Hughes s'est heurté à un problème similaire avec son projet GNOME Software et y a répondu en créant AppData, une application XML dont les applications qui souhaitent apparaître dans GNOME Software doivent embarquer un fichier afin de rendre leurs données (nom, description, captures d'écran) accessibles aisément au programme.

L'idée est intéressante et j'ai décidé de m'en inspirer pour créer GameData, une application XML inspirée d'AppData mais spécialisée pour les jeux vidéo.

<?xml version="1.0" encoding="UTF-8"?>

<game>
  <id>sonic-the-hedgehog</id>
  <license>cc0</license>
  <title>Sonic the Hedgehog</title>
  <description>
    <p>
      In an attempt to steal the six Chaos Emeralds and harness their power,
      Dr. Ivo Robotnik has trapped the animal inhabitants of South Island in
      cybernetic shells and metal capsule prisons.
    </p>
    <p>
      Control Sonic the Hedgehog to stop Robotnik's plans by freeing your
      animal friends and collecting the Chaos Emeralds.
    </p>
  </description>
  <release_date>
    <day>27</day>
    <month>06</month>
    <year>1991</year>
  </release_date>
  <genres>
    <genre>platform</genre>
  </genres>
  <screenshots>
    <screenshot type="default">
      http://info.sonicretro.org/images/6/6f/Sonic1_title.png
    </screenshot>
    <screenshot>
      http://upload.wikimedia.org/wikipedia/en/d/d3/MD_Sonic_the_Hedgehog.png
    </screenshot>
  </screenshots>
  <covers>
    <cover type="default">
      http://upload.wikimedia.org/wikipedia/en/b/ba/Sonic_the_Hedgehog_1_Genesis_box_art.jpg
    </cover>
  </covers>
  <developers>
    <developer url="http://www.sonicteam.com/">Sonic Team</developer>
  </developers>
  <modes>
    <mode min_players="1" max_players="1">local</mode>
  </modes>
  <controllers>
    <controller buttons="4">gamepad</controller>
  </controllers>
</game>

<id />

J'ai commencé à définir GameData sur cette page Web et le format n'est pas encore fixé, si vous voyez le moindre manque ou problème dans la définition du format n'hésitez pas à me le signaler car je souhaite le peaufiner avant de "lancer la production" de ces fichiers.

Je suis également en train d'écrire une bibliothèque en Vala pour manipuler de tels fichiers.

Futur du projet

Même si le projet avance lentement (ma vie passe avant lui) il est loin d'être mort et je souhaite lui mettre un gros coup de polish et étendre ses horizons.

Pour ce faire, je souhaite :
- nettoyer le backend en Vala, retirer toute dépendance superflue comme GTK+, et ce afin de le rendre très portable tant entre langages (Vala est très bon là dessus grâce à GOI) qu'entre environnements ;
- faire un frontend pour GNOME propre, laisser la possibilité de créer d'autres frontends (en prenant Transmission pour modèle) ;
- afin de faire avancer le projet plus vite qu'entre mes seules mains et surtout parce que la création de milliers de GameData est trop pour un seul homme, j'espère monter une communauté (voire un site) autour du projet !

Si vous êtes intéresser à faire avancer le jeu vidéo sous Linux ou la préservation du jeu vidéo, et que vous souhaitez participer, n'hésitez surtout pas à me contacter (le projet étant encore jeune c'est le moment parfait pour ça) !

  • # XML, encore et toujours.... le mauvais choix pour la mauvaise utilisation.

    Posté par . Évalué à 6.

    Note préalable: je fais un sujet spécifiquement sur XML, parce que, voila, ça me gonfle de voir ce truc illisible utilisé pour tout et n'importe quoi.

    Je peux savoir quelle est la raison d'utiliser XML pour l'exemple cité?
    Ca n'a juste… aucun intérêt, si ne c'est de ne pas être maintenable facilement à la main. Je sais que certains sont de vrais fan de XML, mais voici à quoi ressemblerait le même contenu, pour un paquet Debian (qui est quelque chose de bien éprouvé pour ce type d'usage, donc. Et je reprend ici tout, alors que je n'aurai pas forcément utilisé les même clés. En plus, je n'ai pas mis de description courte, vu qu'elle n'existe pas dans le fichier XML…):

    id: sonic-the-hedgehog
    license:cc0
    title:Sonic the Hedgehog
    description:
     In an attempt to steal the six Chaos Emeralds and harness their power,
     Dr. Ivo Robotnik has trapped the animal inhabitants of South Island in
     cybernetic shells and metal capsule prisons.
    
     Control Sonic the Hedgehog to stop Robotnik's plans by freeing your
     animal friends and collecting the Chaos Emeralds.
    release_date: 27/06/1991
    genres: platform
    screenshots:http://info.sonicretro.org/images/6/6f/Sonic1_title.png
     http://upload.wikimedia.org/wikipedia/en/d/d3/MD_Sonic_the_Hedgehog.png
    covers:http://upload.wikimedia.org/wikipedia/en/b/ba/Sonic_the_Hedgehog_1_Genesis_box_art.jpg
    developers:Sonic Team<http://www.sonicteam.com/>
    modes:local<1,1>
    controllers:gamepad<4>
    

    Le public avertis de ce site éclairé aura constaté quelques adaptations libres autours de certains aspects, tels que les modes et les contrôleurs.
    En réalité, pour Debian on aurait utilisé les debtags pour nombre de ces données, comme le genre. D'ailleurs… ceci devrait t'intéresser.

    Je ne sais pas si ce n'est que moi, mais en tout cas ça me semble déjà bien plus lisible (*), à la fois pour l'homme, mais aussi pour un programme ( pas besoin de vérifier la cohérence des balises, notamment ).
    Il aurait aussi été possible d'utiliser JSON, un peu moins pire qu'XML pour l'usage et avec pleins de lib pour l'intégrer directement dans du code, ou bien YAML (clairement plus propre que les langages à balise que sont XML et JSON…).

    Tous ces choix auraient été, il me semble moins ridicules que XML. Oui, je suis un XML hater, et fier de l'être, parce que personne n'a jamais pu me dire en quoi XML est supérieur à tous les autres formats sur tous les usages.

    *: au sujet de la lisibilité, je pense que ce qui l' handicape le plus, c'est le fait que j'ai retranscrit comme une brute les informations provenant d'un XML, sans réfléchir. Et puis, les URL n'aident pas. Je n'ai pas non plus aéré le texte, alors que j'aurai pu, avec notamment des retours à la ligne lorsque le contenu d'une catégorie prends plusieurs lignes.

    • [^] # Re: XML, encore et toujours.... le mauvais choix pour la mauvaise utilisation.

      Posté par (page perso) . Évalué à 5. Dernière modification le 11/11/13 à 17:20.

      Je ne suis pas spécifiquement pro XML mais c'est le format que je connais le moins mal, et celui utilisé par le format dont je me suis inspiré.

      Avec les formats que tu as cités peut-on :

      • gérer proprement plusieurs jeux dans un seul fichier (je parle de centaines) sans que ça devienne illisible ? (je pensais à faire un fichier contenant les jeux de tout un système, système étant en partie une collection de jeux)
      • définir facilement et proprement des sous-formats ? (par exemple un MegaDriveGameData contenant des spécificités à la Mega Drive et étendant GameData)

      Je ne suis pas contre changer de format, mais comme je n'ai absolument rien contre XML (je pensais éventuellement créer une petite application spécialisée pour faciliter la création des GameData, donc la verbosité n'aurait pas tant été problématique).

      • [^] # Re: XML, encore et toujours.... le mauvais choix pour la mauvaise utilisation.

        Posté par . Évalué à 1. Dernière modification le 11/11/13 à 18:12.

        gérer proprement plusieurs jeux dans un seul fichier (je parle de centaines) sans que ça devienne illisible ? (je pensais à faire un fichier contenant les jeux de tout un système, système étant en partie une collection de jeux)
        définir facilement et proprement des sous-formats ? (par exemple un MegaDriveGameData contenant des spécificités à la Mega Drive et étendant GameData)

        Tu n'as qu'a copier/coller 100 fois ton texte dans le même fichier, et me dire que tu trouves ça lisible… en toute bonne foi, bien sûr.

        Enfin, au niveau des formats que j'ai cités: JSON en est capable, celui de debian aussi ( même que c'est ce qui est fait dans "/var/lib/apt/lists/*". Je ne le savais pas, mais ta question m'a poussé à regardé comment c'était foutu…), et je ne doute pas que YAML le puisse aussi, je connais moins ce format (je me le garde juste en mémoire pour le jour ou j'en aurai peut-être besoin. Ceci dit, wikipedia montre très bien ce qu'on peut en faire).

        définir facilement et proprement des sous-formats ? (par exemple un MegaDriveGameData contenant des spécificités à la Mega Drive et étendant GameData)

        Ce que tu dis me fais penser à l'héritage, en POO. C'est le truc que l'on apprend a arrêter d'utiliser à tout bout de champ (comme ce que je prône pour XML en fin de compte) au bout d'un moment, parce que ça pose plus de souci que ça n'en résout.

        Debian résout ce problème de façon très simple: les debtags.

        Un extrait d'un fichier de /var/lib/apt/lists fera un bon exemple, je pense:

        Package: alien-arena
        Version: 7.53+dfsg-3
        Installed-Size: 1885
        Maintainer: Debian Games Team <pkg-games-devel@lists.alioth.debian.org>
        Architecture: amd64
        Depends: libc6 (>= 2.7), libcurl3-gnutls (>= 7.16.2), libfreetype6 (>= 2.3.5), libgcc1 (>= 1:4.1.1), libjpeg8 (>= 8c), libogg0 (>= 1.0rc3), libstdc++6 (>= 4.1.1), libvorbis0a (>= 1.1.2), libvorbisfile3 (>= 1.1.2), libx11-6, libxxf86dga1, libxxf86vm1, libopenal1, alien-arena-data
        Description: Standalone 3D first person online deathmatch shooter
        Homepage: http://red.planetarena.org
        Description-md5: 47823b2859eb6b755a4964a82d53d164
        Tag: game::fps, hardware::input:keyboard, hardware::input:mouse,
         hardware::opengl, implemented-in::c, interface::3d, interface::x11,
         network::client, role::program, uitoolkit::sdl, use::gameplaying,
         x11::application
        Section: contrib/games
        Priority: extra
        Filename: pool/contrib/a/alien-arena/alien-arena_7.53+dfsg-3_amd64.deb
        Size: 832736
        MD5sum: 9dbb8283b1aec54dedf7656dfced98f7
        SHA1: 12d01f66d130690e83329ee2ce524e8981cd2273
        SHA256: dde9ab80f1cf913f73fcbe1110f0c32dfb4a56c47ad8fde13234f2177edff26c
        
        Package: alien-arena-server
        Source: alien-arena
        Version: 7.53+dfsg-3
        Installed-Size: 581
        Maintainer: Debian Games Team <pkg-games-devel@lists.alioth.debian.org>
        Architecture: amd64
        Depends: libc6 (>= 2.7), libjpeg8 (>= 8c), ruby, alien-arena-data
        Description: Dedicated server for Alien Arena
        Homepage: http://red.planetarena.org
        Description-md5: f4a775dfc909f96d9fd86524249092dc
        Tag: game::fps, implemented-in::c, implemented-in::ruby,
         implemented-in::shell, interface::commandline, interface::daemon,
         network::server, role::program, use::gameplaying
        Section: contrib/games
        Priority: extra
        Filename: pool/contrib/a/alien-arena/alien-arena-server_7.53+dfsg-3_amd64.deb
        Size: 267938
        MD5sum: fc2ab2a91de14bd3a41f5564d9addb58
        SHA1: 2f1fd137fbd4d290cd13e0e68472c8cf96341a71
        SHA256: 820885cb501ab2382b6b341093bb2cef626513eee19355eca365508ed5bffa68
        
        Package: alsa-firmware-loaders
        Source: alsa-tools
        Version: 1.0.25-2
        Installed-Size: 192
        Maintainer: Debian ALSA Maintainers <pkg-alsa-devel@lists.alioth.debian.org>
        Architecture: amd64
        Depends: fxload, udev, libasound2 (>= 1.0.16), libc6 (>= 2.4)
        Description: ALSA software loaders for specific hardware
        Homepage: http://www.alsa-project.org/
        Description-md5: 631dd818c28b45f8af844a1ba49ddcd6
        Tag: role::program, use::driver, works-with::audio
        Section: contrib/sound
        Priority: extra
        Filename: pool/contrib/a/alsa-tools/alsa-firmware-loaders_1.0.25-2_amd64.deb
        Size: 38244
        MD5sum: cbfc88429d6c88a3dba19e4ae4272085
        SHA1: 048e9aafaac995d0820fb196a187f21c6655f935
        SHA256: 4282c23deae1f1cd5669d86281f26e7bf58e33421df213548fa14445a1a3baf8
        

        Je ne sais pas pour toi, mais je trouve ça plutôt lisible. Peux-tu faire la même chose, en aussi lisible, avec un format plus riche?

    • [^] # Re: XML, encore et toujours.... le mauvais choix pour la mauvaise utilisation.

      Posté par (page perso) . Évalué à 4. Dernière modification le 11/11/13 à 17:26.

      Je ne suis pas vraiment un fan du XML mais tout n'est pas noir avec XML. L'environnement est très fourni, il y a plein d'outils pour XML.

      Tu peux valider ton document, avec des schémas DTD ou XSD, c'est indispensable pour un service par exemple.

      Tu peux aussi faire des transformations XSLT, pour générer un document XML à partir d'un document XML avec des règles définies dans un document XML.

      Et tu as plein d'outils qui font oublier que derrière tu as du XML.

      Enfin bref, XML c'est un peu plus qu'un dictionnaire clef/valeurs.

    • [^] # Re: XML, encore et toujours.... le mauvais choix pour la mauvaise utilisation.

      Posté par (page perso) . Évalué à 3.

      peut être parce que lorsque tu fabriques la DTD quivabien(c) tu peux fabriquer les fiches en étant certain que sa grammaire est correcte ?

      Que les tags obligatoires y sont, que tous les tags existent… ce genre de chose, en amont et tu ne te retrouves pas, 'potentiellement' avec un fichier texte inexploitable par que le bonhomme aura écrit "Genre :" au lieu de "genres:", maintenant je ne dis pas que c'est la bonne solution, mais je fournis une petite explication sur le pourquoi du xml.

      D'ailleurs si ce format était aussi merdique, on se demande comment il à pu envahir tout le web avec le html.

      • [^] # Re: XML, encore et toujours.... le mauvais choix pour la mauvaise utilisation.

        Posté par . Évalué à 1.

        peut être parce que lorsque tu fabriques la DTD quivabien(c)

        Je veux bien le pourcentage d'utilisateurs du XML qui font le DTD quivabien, stp?
        1%? 2%? 5%? Je ne monterai pas au-delà.

        D'ailleurs si ce format était aussi merdique, on se demande comment il à pu envahir tout le web avec le html.

        En même temps, je n'ai jamais dit qu'il est inutile.

        Ce qui me fait le haïr, c'est à force de le voir partout, pour tout et n'importe quoi, fichiers de configuration y compris. Et qu'on me ressasse que c'est la perfection à longueur de temps à, comme souvent avec moi, eu l'effet inverse, qui fait que dorénavant, je commence toujours par chercher une solution autre qu'XML, et si aucune ne conviens, ce qui n'est pas commun, alors je retombe sur XML.

        Au moins, moi, je suis conscient d'être un hater, je sais pourquoi, et je l'assume, contrairement aux fanboys de ce truc.

        • [^] # Re: XML, encore et toujours.... le mauvais choix pour la mauvaise utilisation.

          Posté par . Évalué à 1.

          Tu devrais peut être jeter un coup d’œil vers les microdata !
          C'est du Web sémantique, HTML5, et tout ce qui est à la mode en ce moment !
          Et en plus c'est pratique, si tu utilises un format standard que plusieurs utilisateurs pourront lire, ils y a plus de chance que les sites web se mettent à l'utiliser.

  • # cmake & multi-frontend

    Posté par . Évalué à 1.

    Au sujet du build system, je te conseille plutôt CMake, ou n'importe quel outil autre que les GNU autotools archaïques.

    Pour les front-end qui varient, c'est une excellente idée, mais c'est un peu comme pour les plug-in, ce n'est pas en en faisant qu'un que tu pourras avoir une interface ( logicielle ) définitive et fonctionnelle. Ce n'est pas que moi qui le dis, lorsque que je faisais des recherches à ce sujet, je suis tombé sur divers documents, dont un de google qui indiquait en gros que les interfaces de plug-in deviennent correctes à partir de 3 plug-in. Je gage que ce sera la même chose dans ton cas, bien qu'on puisse plutôt parler de plugout, puisque c'est le moteur (transmission-common) qui est le plugin d'une interface (transmission-gtk/cli/daemon/qt).
    J'ai le même sentiment a propos des applications comme mpd, bien que le use case soit très différent.

    • [^] # Re: cmake & multi-frontend

      Posté par (page perso) . Évalué à 2.

      Au sujet du build system, je te conseille plutôt CMake, ou n'importe quel outil autre que les GNU autotools archaïques.

      Je jetterai un œil à CMake, j'ai essayé de comprendre Automake mais en vain jusque là…

      Pour les front-end qui varient, c'est une excellente idée, mais c'est un peu comme pour les plug-in, ce n'est pas en en faisant qu'un que tu pourras avoir une interface ( logicielle ) définitive et fonctionnelle. Ce n'est pas que moi qui le dis, lorsque que je faisais des recherches à ce sujet, je suis tombé sur divers documents, dont un de google qui indiquait en gros que les interfaces de plug-in deviennent correctes à partir de 3 plug-in. Je gage que ce sera la même chose dans ton cas, bien qu'on puisse plutôt parler de plugout, puisque c'est le moteur (transmission-common) qui est le plugin d'une interface (transmission-gtk/cli/daemon/qt).
      J'ai le même sentiment a propos des applications comme mpd, bien que le use case soit très différent.

      J'en profiterai pour découvrir Qt d'autres environnements. =)

      • [^] # Re: cmake & multi-frontend

        Posté par . Évalué à 2.

        j'ai essayé de comprendre Automake mais en vain jusque là…

        C'est généralement ce que je rétorque quand on me demande pourquoi je n'aime pas les autotools. J'ai dis cmake, mais ne te laisse pas faire, il y en a pleins d'autres. CMake est juste celui que j'ai testé en 1er après les autotools, parce que plus de gens font plus de bruit à son sujet.

  • # Re: Journal— Projet Badnik, partie 2 : GameData et appel àcontribution

    Posté par (page perso) . Évalué à 3.

    Si un jeu ne peux avoir qu'un seul id pourquoi ne pas en faire un attribut de game ?

  • # Pourquoi un nouveau format?

    Posté par (page perso) . Évalué à 3.

    Je n'ai pas compris, quel problème cherche tu à résoudre avec ton nouveau format qui n'est pas résolu par l'existant?

    Pourquoi AppData ne convient pas?
    Pourquoi ne pas directement prendre les infos dans les .desktop des jeux?

    Ne serait-il pas possible d'avoir un truc générique avec des modules pour les différentes sources d'info, qui permettrait de prendre l'info dans les paquets quand le jeu est un paquet, dans son fichier .desktop quand il en a un, via un émulateur pour les jeux concernés, dans un truc spécifique si besoin et qu'il est présent, …

    • [^] # Re: Pourquoi un nouveau format?

      Posté par (page perso) . Évalué à 2.

      Pourquoi AppData ne convient pas?

      AppData ne prend pas des problématiques propres aux jeux comme le type de contrôleurs, le nombre d'utilisateurs, les modes de jeu (local, lan…)…

      Pourquoi ne pas directement prendre les infos dans les .desktop des jeux?

      Seul un très faible nombre de jeux sont distribués avec un .desktop, je pense notamment aux jeux sur consoles (qui sont distribués sous forme de binaire de rom, d'image disque…) ou autres.

      Ne serait-il pas possible d'avoir un truc générique avec des modules pour les différentes sources d'info, qui permettrait de prendre l'info dans les paquets quand le jeu est un paquet, dans son fichier .desktop quand il en a un, via un émulateur pour les jeux concernés, dans un truc spécifique si besoin et qu'il est présent, …

      C'est la solution de facilité et c'est précisément ce que j'ai tenté de faire en premier lieu et j'ai malheureusement constaté que ça ne marche pas aussi bien que prévu.
      GameData est une partie de la solution que je propose pour résoudre le problème d'obtention des données : ça permet de les distribuer avec l'application gérant les jeux.

      • [^] # Re: Pourquoi un nouveau format?

        Posté par (page perso) . Évalué à 2.

        Ta base ne sera jamais complète, et la mise à jour des infos en fonction des sorties/mise à jour de jeu est un travail de titan, qui ne sera très probablement pas fait suffisamment régulièrement.

        C'est une bonne solution d'avoir plusieurs sources parmis lesquelles figurent les émulateurs, le gestionnaire de paquet et les .desktop.
        Il ne faut pas avoir de sources qui nécessitent un accès internet.
        Tu peux éventuellement avoir ton système en complément pour ajouter les jeux manquants ou les infos qui ne sont pas données par les autres sources, mais ce serait mieux de prendre un standard comme le .desktop et l'étendre pour y mettre les données spécifiques aux jeux.

        • [^] # Re: Pourquoi un nouveau format?

          Posté par (page perso) . Évalué à 2.

          Ta base ne sera jamais complète, et la mise à jour des infos en fonction des sorties/mise à jour de jeu est un travail de titan, qui ne sera très probablement pas fait suffisamment régulièrement.

          L'idée est de se baser sur des BDD en ligne déjà existantes et qui se sont stabilisées, et d'en récupérer les informations fondamentales.

          C'est une bonne solution d'avoir plusieurs sources parmis lesquelles figurent les émulateurs, le gestionnaire de paquet et les .desktop.

          Les émulateurs ne fournissent pas la moindre information, tout ce qu'ils ont, ils le trouvent soir dans les fichiers de jeu (autant dire dans rien du tout), soit dans des bases de données hors ligne (comme ce que je compte mettre en place).

          Il ne faut pas avoir de sources qui nécessitent un accès internet.

          C'est précisément un de mes buts : me passer de l'accès à internet autant que possible en fournissant en local une partie des données dans les GameData.

          Tu peux éventuellement avoir ton système en complément pour ajouter les jeux manquants ou les infos qui ne sont pas données par les autres sources, mais ce serait mieux de prendre un standard comme le .desktop et l'étendre pour y mettre les données spécifiques aux jeux.

          À quoi bon utiliser quelque chose de standard si je dois l'adapter derrière, et donc me priver de l'écosystème de ce standard ? Je ne suis pas contre utiliser un format particulier, mais ce qui compte avant tout ce n'est pas la forme mais la disponibilité des données en local.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.