Forum général.général Lecture des cartes Vitales2

Posté par  . Licence CC By‑SA.
Étiquettes :
6
24
juil.
2013

Bonjour, je réagis suite au billet http://linuxfr.org/users/labiloute/journaux/la-lecture-des-cartes-cps-sous-linux (qui date un peu…)

Nous sommes en train de développer un équivalent sous license GPLv3 des API de lecture sesame / vitale (projet Alibaba).

La documentation du projet et le code source peuvent être trouvés sur https://www.assembla.com/spaces/alibabaAPI/wiki

Ce serait sympa de mettre à jour le billet http://linuxfr.org/users/labiloute/journaux/la-lecture-des-cartes-cps-sous-linux en signalant l'existance d'un équivalent libre des API de lecture proprio.

Cdt

  • # et pourquoi pas faire un commentaire au journal sus-cité ?

    Posté par  . Évalué à 2.

    Î_tout est dans le titre _Î

  • # Documenter le protocole ?

    Posté par  (site web personnel) . Évalué à 2.

    Il n'y a pas l'air d'y avoir grand chose dans la doc: https://www.assembla.com/spaces/alibabaAPI/wiki/Base_de_connaissances_SESAM_Vitale

    Il y a plus de doc dans le source genre https://www.assembla.com/code/alibabaAPI/subversion/nodes/7/trunk/src/main/java/fr/sesamvitale/alibaba/model/AssMaladie.java#ln69 mais ca serait sympa de publier les infos directement.

    Personnelement je prefere jouer avec cardpeek (pas besoin de compiler un truc en java a chaque test) mais depuis 3 ans que https://code.google.com/p/cardpeek/source/browse/trunk/dot_cardpeek_dir/scripts/vitale_2.lua existe personne n'a bossé dessus :(

    (et moi j'ai déja fait le navigo et faudrait que je progresse sur mobib donc j'ai une excuse, j'ai actuellement que la date du début des abonnements et le nombre de voyages restant sur chaque, faut que je retourne a Bruxelles ou que je trouve des volontaires)

    • [^] # Re: Documenter le protocole ?

      Posté par  . Évalué à 2.

      Le projet en est à ses balbutiements, pour l'instant, je suis seul à bosser dessus.

      Pour ce qui est de cardpeek, tu ne pourras plus lire directement les données de ta vitale2.
      Celles-ci sont encodées d'une facon assez tordue.

      Pour ce qui est de la doc, satellitaire pour l'instant, des infos complénmentaires seront publiées aussitôt qu'une version stable sera disponible :
      L'API étant en cours de réverse, il se peut qu'il y ait régulièrement des changements importants dans ma compréhention du fonctionnement des vitales.

      Le reverse des API vitale est un boulot vraiment casse-tête. Si quelqu'un était intéréssé par le projet, j'accueillerai avec joie un autre contributeur…

      • [^] # Re: Documenter le protocole ?

        Posté par  (site web personnel) . Évalué à 2.

        Lire directement n'est pas le point :)

        En le faisant en Java tu as besoin de compiler le truc à chaque changement. J'utilise cardpeek quand je reverse une carte, juste parce que c'est un script que tu peux éditer directement (meme si j'aime pas LUA).

  • # matériel

    Posté par  . Évalué à 2.

    Pour ceux qui s'y sont déjà intéressés, quel lecteur, dans une gamme de prix raisonnable, conseilleriez vous de manière à pouvoir lire un maximum de type de cartes différentes, avec et sans contact ?

  • # Mise à jour

    Posté par  . Évalué à 1. Dernière modification le 04 octobre 2013 à 00:05.

    Je me permets de repasser, le projet arrive a une première version stable. La totalité des algorithmes d'encodage ayant été réversés.

    Ce serait sympa si des gens pouvaient tester un peu et faire des retours pour s'assurer que tout est OK.

    J'ai du faire tout le RE avec 2 ou 3 cartes vitales de test. Ca permettait de détecter des cas tordues qui m'auraient échappé.

    Enfin bref, normalement, ca fonctionne bien =).

    Si il y a des gens intéressés par les algos ou le projet, il a toutes les infos qui faut sur https://www.assembla.com/spaces/alibabaAPI/wiki .

    Maintenant, je vais attaquer la partie CPS.

    Si j'ai le temps, je vous écrirai un petit article pour présenter le projet.

    +++

Suivre le flux des commentaires

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