On a pas mal de plugins (officiels ou non) qui sont basés sur des API tierces, des lib externes libres, voir sur des sites internet distants (méteo, etc.)
A la vue de certains posts, je pense qu’il serait bon dans la doc, en introduction de préciser ces dépendances et ce que cela peut induire dans le temps afin de faire prendre conscience aux users qu’un dysfonctionnement peut arriver sans que cela soit forcément du à l’univers Jeedom
En effet un changement api arrive, une refonte du site internet, une lib abandonnée etc…
Un petit laïus tout fait ou on aurait qu’a changer le nom de l api ou le site distant etc.
Chacun saurait alors que parfois le plugin météo choisit ne fonctionne plus car le site distant est HS ou modifié, que le plugin doit évoluer car l’API a complétement changé.
Bref cela apparait clair et évident pour certains mais ce n’est pas le cas pour tous.
J’ai pris l’habitude de mettre dans la FAQ chaque nouveau cas rencontré sur le forum, afin de limiter les doublons - pour peu que l’utilisateur lise tout jusqu’à la FAQ -
Bonjour,
Très bonne idée qui éviterais les surprises pour ceux qui ignorent les liaisons entre api et plugin.
Pourquoi pas simplement sur le Market à coté ou en dessous du nom du développeur rajouter entre parenthèse (plugin Lié à l’API actuelle du site XXX) ainsi « l’acheteur » le voit assurément au moment de son achat.
Cordialement
J’ai écrit un tel paragraphe dans la doc du plugin TaHomaLocal que j’ai soumis récement à l’équipe Jeedom. Basé sur l’API locale Somfy, il est effectivement dépendant du bon vouloir de Somfy pour sa perénnité.
Par contre, en lisant ton post (fort pertinent), je vais le modifier pour rajouter Jeedom également qui ne peut être tenu responsable d’une évolution majeure de l’API.
Hello,
Petit hs j’en profite pendant que je peux répondre
J’ai une vieille Tahoma, je suppose que l’api n’est pas implémentée ?
je ne vois rien dans le menu qui me laisse de l’espoir.
Ton avis ?
Merci
Bonjour,
‹ Vieille Tahoma ›, c’est un peu vague … Il faut vérifier sur ton compte Somfy si tu peux la passer en mode dit « Developpeur ».
Mais je ne souhaite pas engager un échange ici parce que c’est effectivement hors sujet et je ne voudrais pas polluer le post de @anon53349806.
Tu penses à une information dans la doc ou bien une information dans les paramètres du plugin et qui apparaîtrait un peu à la façon d’un plugin non officiel ?
Je pense que cela ne va pas être simple car quasiment tous les plugins dépendent de librairie tierce et/ou accès à un site qui peut du jour au lendemain être modifié ou tout simplement supprimé.
Tous les plugins que j’utilise ont soit des dépendances (librairies tierces qui peuvent plus ou moins être pérenne), soit accès à un cloud par le biais d’une API qui peut être modifié ou tout simplement pire si le fabriquant arrête tout simplement cet accès cloud.
En tous les cas et pour ma part, je vais ajouter un paragraphe tout en début de la documentation de chacun de mes plugins.
La doc est touffue, rajouter une page elle ne serait jamais lue, il faudrait quasiment ajouter un bandeau sur chaque page, pour juste essayer de sensibiliser les utilisateurs à ce genre de problème - enfin, pour ceux qui lisent la doc
L’univers informatique est une suite presque infinie de librairies / frameworks / API, et Jeedom ne serait rien sans tout ce patchwork. Et c’est vrai que ça nous semble évident à la longue, mais c’est obscur pour l’utilisateur qui utilise Jeedom pour la 1ere fois il s’attend à ce que ça marche tout seul (quelle désillusion)
Plutôt qu’une doc, je crois que le secret est plutôt dans des messages d’erreur à rallonge, éventuellement avec un lien vers la doc, mais voila par exemple, au lieu de API Erreur 500 un message « Impossible de se connecter à l’API ‹ météo.locale.com › vérifiez votre token [lien doc] » la on a fait 80% du boulot
En tant que développeur on cherche parfois à faire une gestion des erreurs générique, mais c’est une erreur, chaque erreur est spécifique et doit être traitée avec le bon message.
Après, pour le cas spécifique des API, un bouton test dans la page de configuration peut être utile aussi.
Il faut faire comme pour la pub ou pour faie évoluer les mentalités : du bourrage de crane.
Message à chaque fois que l’utilisateur rentre sur la page de config pour lui rappeler la foutue dépendance du plugin au machin externe.
Autre idée, rajouter une dépendance au plugin vers un 2ème cloud « Jeedom » ou celui du développeur afin de pouvoir envoyer certaines infos dynamiquement au plugin et à l’utilisateur sur le problème en cours non prévu par la version du plugin installée.
Exemple, un plugin ne fonctionne plus à cause d’une API qui a changé, dès les premières plaintes de certains utilisateurs, le développeur pourrait mettre l’information du problème en cours sur son cloud que le plugin irait lire automatiquement. Le message pourrait être « Le site machin-truc vient de modifier son API. Merci de patienter et de ne pas gueuler sur le forum, un correctif du plugin est en cours. » L’utilisateur qui s’aperçoit d’un souci, irait sur la page config du plugin et verrait ce message.
Bon, si on pousse le raisonnement, on pourrait aussi autoriser le développeur à éffectuer certaines MAJ en douce, un peu comme les contructeurs automobiles avec les MAJ logiciels. L’utilisateur ne constate pas de problème et ne pose pas de question.
-
