J'adore ce genre de réponse. «y'a une api, c'est bon, tu peux coder ton client dans ton coin». Ça me fait penser à ceux qui me traitent de passéiste à vouloir garder XMPP pour qu'on continue à avoir nos clients desktops et pas des bousins en JavaScript, avec exactement le même argument de l'API.
La présence d'une API, si tant est qu'elle soit complète, n'est pas suffisant. Ne serait-ce que du point de vue du développeur d'un client : Si demain une fonctionnalité est ajoutée sur l'interface web mais absente de l'API, et qu'elle rend des éléments invisibles, comment faire ? Comment être notifié de l'arrivée de nouvelles APIs ? Et c'est pas un travail anodin, c'est long et fastidieux de faire un client pour ce genre d'usage.
Puis du point de vue d'un utilisateur qui explique qu'on lui retire son outil, «t'as qu'à t'en coder un», c'est une excellente idée ma foi...
Également, d'un point de vue philosophique, pourquoi est-ce-que je développerais un client pour un logiciel, certes libre, mais avec un protocole propriétaire à ce logiciel, et chapeauté par une entreprise dans un paradis fiscal ? Dans mon taf précédent, on subissait Slack, j'avais commencé à coder un client alternatif en Qt... Je l'ai utilisé un temps, mais j'en ai arrêté le développement, car au final rendre Slack utilisable, c'est améliorer cet outil, et c'est clairement pas à moi de le faire sur mon temps libre...
Je n'ai pas cherché mais il y a probablement déjà des interfaces pour terminaux.
J'ai cherché, je n'en ai pas trouvé. En tout cas pas dans les paquets Archlinux, ni les paquets Debian, ni sur Internet.
D'ailleurs, ça n'a pas été listé lors de la discussion du projet Debian sur une éventuelle utilisation de Discourse, cf https://lwn.net/Articles/817668/
[^] # Re: Pas trop convaincu
Posté par Pinaraf . En réponse à la dépêche La communauté GNOME remplace ses listes de discussion par Discourse. Évalué à 10.
J'adore ce genre de réponse. «y'a une api, c'est bon, tu peux coder ton client dans ton coin». Ça me fait penser à ceux qui me traitent de passéiste à vouloir garder XMPP pour qu'on continue à avoir nos clients desktops et pas des bousins en JavaScript, avec exactement le même argument de l'API.
La présence d'une API, si tant est qu'elle soit complète, n'est pas suffisant. Ne serait-ce que du point de vue du développeur d'un client : Si demain une fonctionnalité est ajoutée sur l'interface web mais absente de l'API, et qu'elle rend des éléments invisibles, comment faire ? Comment être notifié de l'arrivée de nouvelles APIs ? Et c'est pas un travail anodin, c'est long et fastidieux de faire un client pour ce genre d'usage.
Puis du point de vue d'un utilisateur qui explique qu'on lui retire son outil, «t'as qu'à t'en coder un», c'est une excellente idée ma foi...
Également, d'un point de vue philosophique, pourquoi est-ce-que je développerais un client pour un logiciel, certes libre, mais avec un protocole propriétaire à ce logiciel, et chapeauté par une entreprise dans un paradis fiscal ? Dans mon taf précédent, on subissait Slack, j'avais commencé à coder un client alternatif en Qt... Je l'ai utilisé un temps, mais j'en ai arrêté le développement, car au final rendre Slack utilisable, c'est améliorer cet outil, et c'est clairement pas à moi de le faire sur mon temps libre...
J'ai cherché, je n'en ai pas trouvé. En tout cas pas dans les paquets Archlinux, ni les paquets Debian, ni sur Internet.
D'ailleurs, ça n'a pas été listé lors de la discussion du projet Debian sur une éventuelle utilisation de Discourse, cf https://lwn.net/Articles/817668/