Mes utilisateurs aiment beaucoup l’affichage des “présences” mais se plaignent que ce n’est pas fiable du tout. Un contact hors ligne peut être rouge pour certains et orange pour d’autres.
Y a-t-il moyen de faire quelque chose à ce propos? comme par exemple forcer le nettoyage ou une remise à zéro de la DHT locale pour un contact donné?
ok; la présence reçue est rien, 0, 1 ou 2. (bleu, rouge, orange et vert pour mon client home made).
j’ai une douzaine de clients actifs sur notre DHT de tests (pas la DHT globale). Un client éteint (donc présence = 0 (rouge)) est souvent vu comme présence = 1 (orange) par certains clients alors que les autres clients voient bien présence = 0 (rouge). C’est un souci pour nos utilisateurs (beta testeurs) qui s’en plaignent. J’aimerais donc pouvoir forcer le nettoyage ou une remise à zéro de la présence connue de la DHT locale pour un contact donné et laisser ensuite la synchro automatique des noeuds DHT repousser la bonne valeur.
Je crois comprendre que ce n’est structurellement pas possible.
Je vais donc revoir mon processus pour ne pas utiliser directement les valeurs 0 et 1 de la présence mais pour déclencher (signal SubscriptionStateChanged) un sendTextMessage (reçu via le signal IncomingMessage) car si celui-ci abouti la présence passe à 2 (vert) et n’afficher que rouge et vert…
Nota bene: Par choix, nous n’utilisons pas la gestion des contacts par jami-daemon ni les swarm car nous ne persistons rien sur disque! Nous ne faisons que des appels et messages courts directs (sans historique ni stockage) entre jami-ids (jid) sur base d’une liste en mémoire alimentée par un autre processus.
Post scriptum: hors de cette “présence” mensongère, les béta testeurs sont enchantés du “produit”.
Si sendTextMessage et IncomingMessage venaient à être abandonnés par jami-daemon, je fourcherai la dernière version qui les implémente afin de ne pas perdre cette fonctionnalité essentielle…