URL: https://linuxfr.org/users/illwieckz/journaux/decrire-les-services-servis-et-comment-s-y-connecter Title: Décrire les services servis et comment s'y connecter Authors: Thomas Debesse Date: 2012年07月05日T23:45:35+02:00 License: CC By-SA Tags: firefox Score: 18 [Discutant de protocoles, de format, d'API etc.](http://linuxfr.org/news/et-voici-movim-0-5-snowball#comment-1364901) dans les commentaires de la dernière dépêche [Et voici Movim 0.5 « Snowball » !](http://linuxfr.org/news/et-voici-movim-0-5-snowball), je me suis réinterrogé sur la nécessité d'un (format/protocole/api) très très [KISS](http://fr.wikipedia.org/wiki/Keep_it_Simple,_Stupid) qui permettrait à un serveur d'identité de décrire les services disponible aux dites identités, et les protocoles, serveurs utilisés et autres détails techniques qui sont toujours à retrouver sur des obscures pages web et au fin fond des FAQ. Je trouve que c'est un truc tout bête qui manque beaucoup... Par exemple, comment faire un client mail qui serve uniquement à se connecter à une boîte mail distante, mais sans conservation de la session, tout comme on lance une session Firefox dans un cyber café sans enregistrer aucun mot de passe, ou quand on lance la "navigation privée" chez un ami ou l'école/le boulot pour ne rien laisser sur le poste de travail ? Je pense que ce genre de logiciel manque vraiment. Je trouve que le client-mail "sans conservation des données" est un bon exemple, car il est parlant pour l'utilisateur et pour l'administrateur, et il répond à un vrai besoin. Quand l'administrateur assure déjà des tas de services en lignes pour que ce soit accessible depuis le boulot, ou en itinérance sur les smartphones des utilisateur, et correctement sauvegardé, devoir prendre en charge les mailbox locales dans les procédures de sauvegarde c'est un peu gaspiller du temps et de l'argent. La solution choisie aujourd'hui est d'utiliser un webmail, mais c'est pas vraiment la panacée. Pour l'utilisateur, il veut juste pouvoir se connecter et se déconnecter au service, comme sur un vulgaire site internet. Tous les logiciels comme Evolution, Thunderbird etc. ne répondent pas au besoin. Il faudrait pouvoir se connecter à sa boîte mail comme les ados se connectaient à MSN et se déconnectaient aussi simplement : en donnant son adresse et son mot de passe ! Mais vu ce qu'on attend d'un logiciel de mail aujourd'hui, c'est infaisable : il faut connaître le serveur IMAP, la méthode de connexion, le port, le serveur SMTP, la méthode de connexion, le protocole qui gère les contact, le serveur de contact, le protocole qui gère le calendrier, le serveur du calendrier, il faut connaître la forme de l'identifiant (si l'adresse est blabla@example.com, c'est blabla l'identifiant, ou bien blabla@example.com ?). Un enfer... Il suffirait d'une simple méthode de description, par exemple un simple fichier standardisé accessible sur http://example.com/services qui décrive les services associés aux identités servies, et les différents serveurs/protocoles et autres détail pour tout les comptes de ce serveur. Alors il suffirait seulement de désactiver la mise en cache locale d'un logiciel comme [Geary](http://yorba.org/geary/) pour pouvoir se passer de la lourdeur d'un webmail, et si un tel logiciel était rendu possible par une aussi simple méthode, et devenait répandu, on pourrait se passer des webmail, et on pourrait proposer plus facilement des services alternatifs à gmail/ymail/hotmail/etc. ! Et puis... lorsque les paradigmes de gestion de boîte au lettre évoluent (les dossiers de l'imap versus les tags de gmail), il serait envisageable d'élaborer un protocole pour les décrire. Aujourd'hui, puisque tout se fait en webclient (webmail, webchat), on n'élabore plus de protocoles, comme on n'élabore plus de protocole, on ne fait plus de client, on fait des webclient, le serpent se mort la queue. Alors qu'il pourrait être si simple qu'un simple ``GET /services`` sur un serveur quelconque puisse répondre : ```text mailbox: server:imap.example.com proto:imap4+ssl port:993 login:complete smtp: server:smtp.example.com proto:smtp+starttls port:465 login:complete xmpp: server:talk.example.com ... calendar: ... addressbook: ... x-board: x-url:http://example.com/board ... ``` On peut aussi imaginer un protocole simple de clé/valeur, mais ce n'est peut-être même pas nécessaire, on peut aussi imaginer la description de plusieurs protocoles supportés pour une même tâche, et de préciser lequel est déclaré préférable, décrire des protocoles non standardisés. C'est simplissime, mais qu'est ce que ça manque ! Si on ne fait pas des trucs aussi simple, on est condamné à n'avoir que des logiciels qui ne savent se connecter qu'aux "assez grand pour avoir été référencé", et là encore le serpent se mort la queue : on n'ose pas développer de client (ou ce n'est accessible qu'aux geeks), on n'ose pas proposer des serveurs alternatifs (ou ce n'est accessible qu'aux geeks). L'émergence des smartphones nous a donné une chance énorme : tous les services en lignes se sont mit à vanter à leur services via imap etc. Il parait que même hotmail soit accessible en imap, ils ont bien été obligé de le faire pour ne pas perdre la clientèle des smartphones ! On est donc à une époque charnière : les faibles capacités de nos ordinateurs de poches ont remit au goût du jour l'usage de logiciel client et de protocoles standardisés, mais la puissance de ces mêmes ordinateurs de poches venant à s'améliorer, les webclient vont refleurir sur ces machines et cette petite bulle de standardisation pourra bientôt éclater. Ce serait dommage de ne pas profiter de cette chance inattendue pour travailler au désengorgement des "grands" et à la diversification des fournisseurs de services, pour notre bien à tous. Mais pour que tout soit simple, parfois on a juste besoin d'un peu, un tout petit peu de description ! Alors peut-être que ça existe déjà et que ce n'est pas utilisé, mais dans ce cas, pourquoi ? Qu'en pensent tes collègues et amis, Nal ?

AltStyle によって変換されたページ (->オリジナル) /