J'ai du mal à croire que "se farcir toutes les XEP" soit plus long et compliqué que réécrire tout ce dont on a besoin de 0. Surtout qu'on parle ici d'un protocole qui pourrait utilisé des briques éprouvées plutôt que des nouvelles. Un bogue dans un protocole, ça me semble autrement plus chiant que dans une implémentation particulière.
Encore une fois: XMPP a ici l'avantage de son ancienneté.
Les extensions et leur nombre est une force. Il ne faut pas tout lire quand on veut implémenter quelque chose, les extensions sont utiles pour différents domaines et leur nom suffit en général à identifier ce dont on a besoin, + quelques unes qui sont indispensables comme discovery (qui permet de savoir quelles fonctionnalités sont disponibles, ou si on parle à un serveur, un client, un service MUC, un transport, etc) ou data forms (qui permet d'échanger des données de manière standardisées). Ces 2 dernières extensions sont simples à comprendre, et générique elle sont réutilisées partout. Ce qui fait qu'une fois implémentées, il suffit de réutiliser le code pour adapter à un cas particulier (par exemple discovery sert à savoir quelles commandes ad-hoc sont disponibles, ou plus concrètement ça me permet de savoir ce que je peux faire pour administrer mon serveur prosody depuis mon client XMPP).
Quand 2 extensions font la même chose, la meilleure est gardée et l'autre est dépréciée.
Bref, quelqu'un qui utilise XMPP pour commander un robot ne va pas utiliser la même chose que quelqu'un qui fait un logiciel de microblogage, ou que quelqu'un qui s'en sert pour faire du transfert de fichiers. L'intérêt d'avoir tous ces domaines dans des XEPs et qu'on parle la même langue, et du coup on est compatible, on a un seul compte, on peut changer de logiciel, etc. Comme je l'ai dit plus bas, on retrouve la philosophie Unix: chaque XEP fait 1 chose, et la fait bien (et du coup il en faut beaucoup).
Beaucoup d'entreprises utilises XMPP avec des trucs à eux qu'ils ne documentent pas, c'est possible aussi. Ils ont une base solides avec de nombreuses implémentation, et on juste à adapter l'existant à ce qu'il leur faut.
De même, "se farcir toutes les couches basses de XMPP" est-il vraiment un chemin de plus grande résistance que d'inventer et implémenter de nouvelles couches basses?
« les couches basses » c'est les RFC (6120, 6121, 6122), et ça n'est pas très compliqué à comprendre. En plus il ne doit pas y avoir beaucoup de langages où il n'existe pas de bibliothèque qui implémente ça.
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Pas seul dans la matrice. Évalué à 3.
Les extensions et leur nombre est une force. Il ne faut pas tout lire quand on veut implémenter quelque chose, les extensions sont utiles pour différents domaines et leur nom suffit en général à identifier ce dont on a besoin, + quelques unes qui sont indispensables comme discovery (qui permet de savoir quelles fonctionnalités sont disponibles, ou si on parle à un serveur, un client, un service MUC, un transport, etc) ou data forms (qui permet d'échanger des données de manière standardisées). Ces 2 dernières extensions sont simples à comprendre, et générique elle sont réutilisées partout. Ce qui fait qu'une fois implémentées, il suffit de réutiliser le code pour adapter à un cas particulier (par exemple discovery sert à savoir quelles commandes ad-hoc sont disponibles, ou plus concrètement ça me permet de savoir ce que je peux faire pour administrer mon serveur prosody depuis mon client XMPP).
Quand 2 extensions font la même chose, la meilleure est gardée et l'autre est dépréciée.
Bref, quelqu'un qui utilise XMPP pour commander un robot ne va pas utiliser la même chose que quelqu'un qui fait un logiciel de microblogage, ou que quelqu'un qui s'en sert pour faire du transfert de fichiers. L'intérêt d'avoir tous ces domaines dans des XEPs et qu'on parle la même langue, et du coup on est compatible, on a un seul compte, on peut changer de logiciel, etc. Comme je l'ai dit plus bas, on retrouve la philosophie Unix: chaque XEP fait 1 chose, et la fait bien (et du coup il en faut beaucoup).
Beaucoup d'entreprises utilises XMPP avec des trucs à eux qu'ils ne documentent pas, c'est possible aussi. Ils ont une base solides avec de nombreuses implémentation, et on juste à adapter l'existant à ce qu'il leur faut.
« les couches basses » c'est les RFC (6120, 6121, 6122), et ça n'est pas très compliqué à comprendre. En plus il ne doit pas y avoir beaucoup de langages où il n'existe pas de bibliothèque qui implémente ça.