j’ouvre un nouveau thread car écrire 3 fois de suite sur un existant est bloquant…
J’ai bien progressé dans l’introspection de l’écosystème Jami. Je suis loin de le maîtriser (il est complexe) mais j’ai assez de résultats pour envisager une itération vers le sujet…
je sais faire, en Gtk4+Adw sous Phosh (Debian Trixie):
échanges vocaux (hors contacts)
échanges de messages textuels direct (hors contacts ou swarm)
Le swarm pose un souci de saturation de la bande passante locale lors d’une reconnection. Or un mobile se déconnecte/reconnecte souvent (selon mes observations low-level). Du coup, je l’ai écarté pour le moment autant que la gestion des contacts intégrés car là également je trouve que le swarm pollue les contacts en forçant l’établissement d’une conversation avec chaque contact où la “confiance” est établie car détruire une conversation en recrée une instantanément… Pas moyen d’avoir une liste de contacts (dans Jami; c’est possible en dehors) sans conversations liées (ni le traffic réseau lié)…
Ceci étant, j’aimerais connaître les attentes fonctionelles d’éventuels utilisateurs pour un jamiphone basé sur phosh?
J’en développe quelque chose d’approchant pour un besoin interne mais peut-être je pourrais ouvrir si le jeu en vaut la chandelle…
J’ai ouvert un fil de discussion sur le sujet car Jami ne se comporte pas correctement sur le réseau local dernièrement. Il y a de plus en plus d’utilisateurs qui remontent ce type de problème. Si vous avez plus de détails sur ces anomalies, n’hésitez pas à contribuer à cette discussion pour amener à sa résolution.
Aussi, à propos d’un jamiphone basé sur Phosh, un des points faibles souvent décrié de Jami sous Android est son interface utilisateur non-intuitive. Par exemple, Jami supporte la VoIP avec SIP, mais chaque mode VoIP ou natif Jami a une interface d’utilisation différente et le paramétrage des comptes n’est pas unifié, ni même les carnets de contacts. Pensez aux utilisateurs et à leur diversité lors du développement, avant même les capacité techniques du jamiphone. Vos premiers utilisateurs seront les meilleurs promoteurs de votre logiciel…
Je ne m’inspire pas du client Jami officiel car non plus je n’aime son interface.
Je vise une interface unique permettant les appels ofono, jami-p2p et jami-SIP
Je part d’une liste de contacts ([alias, id, is_ofono, is_p2p, is_sip]) pour lesquels l’utilisateur peut envoyer un message instantané court non archivé (conf_mgr.sendTextMessage), participer à une conversation archivée (pas sur que je conserve cela) et passer un appel (vocal uniquement pour le moment n’ayant pas encore trouvé comment gérer les flux vidéos).
Pour le moment, je charge mes contacts depuis un CSV mais, je pense completer cette liste de contacts en me connectant à GNOME Evolution Data Server (EDS) pour y pomper les contacts disposant d’un numéro de téléphone et s’abonner aux signaux d-bus afférant à leurs éventuelles mise à jour par une autre application; les contacts du compte jami de type RING également avec souscription aux signaux de mise à jour; et probablement les contacts d’un compte jami de type SIP (à vérifier. Je n’ai pas encore abordé SIP).
Le focus principal étant la gestion d’appels simultanés utilisant différents protocoles car c’est mon cas personnel d’usage quasi quotidien
Les messages courts non archivés sont dans la boîte.
Pour les conversations j’hésite encore. Peut-être je devrais avoir 3 applications séparées pour la voix, les SMS et les conversations…
Avec, j’espère (si j’y arrive), des fonctions avancées telles que la fusion d’appels en appel de groupe (jami le prévoit; il devrait y avoir un moyen d’y intégrer un appel ofono en le proxyfiant dans jami)…
Je reste à l’écoute d’idées à éventuellement ajouter mais je veux également éviter de fabriquer une usine à gaz. Le guideline KISS est d’actualité
protocole: XMPP (avec chiffrement de bout en bout)
protocole: Signal
(°) j’ai également écrit un client complet pour EDS; voué à remplacer gnome-contacts (°°) comme cette app ci est vouée à remplacer gnome-calls, en ajoutant les champs ad-hoc pour les différents protocoles supportés. Le format vCard 4 spécifie comment faire. Ainsi le carnet d’adresse partagé du téléphone supportera as is les applications GNOME existantes mais également les applications exposant/utilisant d’autres protocoles que PSTN ou email (les 2 prévus de base dans gnome-contacts)
(aucune archive ni log)