Comment ajouter la prise en charge de nouveaux services à Friends?


19

Avec l'arrivée de la nouvelle application d'amis dans Ubuntu, il m'est venu à l'esprit que l' ajout de la prise en charge d'Instagram dans la chronologie serait cool. J'ai aussi pensé que je pourrais essayer moi-même, mais j'ai du mal à trouver des documents.

Existe-t-il une spécification décrivant ce qui est nécessaire pour chaque protocole? Comment fonctionne l'authentification? Le support devrait-il être ajouté aux comptes ubuntu en ligne en premier ou existe-t-il un moyen pour les amis d'enregistrer le nouveau protocole?

Il est très nouveau et porte un nom très difficile à Google, donc tout pointeur dans la bonne direction serait apprécié.


C'est le meilleur que j'ai pu trouver pour l'instant: bugs.launchpad.net/ubuntu/+source/friends/+bug/1156979 et code.launchpad.net/~robru/gwibber/friends MAIS on dirait que vous pouvez utiliser ce qui a été utilisé pour Gwibber (?)
Rinzwind

Eh bien, le code des protocoles pris en charge semble vivre: bazaar.launchpad.net/~super-friends/friends/trunk/files/head:/… Mais ce que j'aimerais vraiment voir, c'est une spécification décrivant les capacités et autres. ..
andrewsomething

C'est encore tôt;)
Rinzwind

Quelqu'un m'a donné tumblr plz.
Khurshid Alam

Réponses:


34

Auteur des amis ici.

En effet, comme vous le soupçonniez, la prise en charge est requise dans les comptes en ligne Ubuntu avant de pouvoir être ajoutée à Friends. L'architecture des amis dépend fortement de l'UOA afin de faire toutes les autorisations et de gérer toutes les clés API pour nous. Mon exemple préféré est LinkedIn, car c'est jusqu'à présent le seul protocole auquel la communauté a contribué. Le plugin UOA est principalement composé de deux fichiers XML, plus un peu de supercherie de configuration automatique, qui ressemble à ceci. (faites défiler vers le bas pour le diff, qui montre clairement chaque chose qui devait être ajoutée pour que LinkedIn fonctionne).

Une fois que vous avez fait la même chose pour votre protocole, vous devez proposer la fusion contre lp: compte-plugins et demander à Mardy de les examiner, les approuver et les fusionner. Une fois que cela est en place, vous pouvez commencer à écrire le plugin friends, qui sera écrit en Python 3.

Maintenant, l'une des améliorations majeures majeures que Friends introduit par rapport à Gwibber est l'utilisation de sous-classes. Dans le code Gwibber d'origine, absolument rien n'a été fait avec les sous-classes, donc chaque nouveau plugin de protocole était un énorme hackjob de copier-coller de divers bits de fonctionnalités de bas niveau. Lors de la mise en œuvre de Friends, j'ai pris grand soin d'extraire les fonctionnalités communes dans une superclasse, qui peut être facilement sous-classée et modifiée. La superclasse a également beaucoup de docstrings, que vous devez consulter lors de votre démarrage. Malheureusement, nous n'avons pas encore configuré sphinx pour les publier, vous n'aurez donc qu'à lire le code pour l'instant.

Il est important de garder à l'esprit que le nom de votre classe doit correspondre au "nom d'utilisateur" utilisé, sans tenir compte de la casse. Donc, si vous avez défini le nom de fournisseur comme étant instagram, vous devez créer le fichier protocols/instagram.pyet nommer votre classe Python Instagram.

Les deux méthodes les plus importantes que vous devez absolument implémenter pour que votre plugin fasse réellement quelque chose, sont appelées _whoamiet receive. Ceux-ci sont bien documentés dans base.py (lié ci-dessus), mais fondamentalement, la _whoamiméthode sera appelée automatiquement et transmise dans un dict qui représente un blob JSON déjà analysé qui nous a été fourni par le service lorsque l'authentification s'est produite. Si vous êtes chanceux, ce dict contiendra votre nom d'utilisateur Instagram, votre identifiant utilisateur et votre nom d'affichage, mais sinon, vous devrez effectuer un appel d'API secondaire afin de recueillir ces informations. Veuillez consulter Facebook._whoamiun exemple de protocole qui n'a pas fourni les informations à l'avance et qui nécessitait un appel d'API supplémentaire à partir de la méthode, et consultezTwitter._whoami pour un exemple d'un protocole qui nous a donné tous les détails dont nous avions besoin dès le départ.

Ensuite, la receiveméthode est responsable de l'appel de l'API qui interroge le service pour les nouveaux messages. Celui-ci est un peu plus libre, car chaque API REST est légèrement différente, vous devez donc vous référer aux documents API du site Web pour savoir exactement ce qui doit être fait ici. En http.py nous fournissons Uploaderet les Downloaderclasses qui le rendent facile de faire des appels API REST, et peut même analyser les réponses du serveur JSON pour vous. Il est important d'utiliser ces classes de commodité car elles s'encapsulent libsoup, qui est configurée pour honorer les paramètres du proxy GNOME (vous vous souvenez peut-être de la terrible prise en charge des proxy par Gwibber, eh bien nous avons corrigé tout cela maintenant).

Une fois que vous avez reçu la réponse de l'API du serveur, vous devez la stocker dans notre DeeModel (où Gwibber a utilisé un blob JSON vidé dans une base de données sqlite pour stocker vos messages, nous utilisons un DeeModel, qui est fondamentalement juste une base de données qui partage l'état sur DBus, ce qui permet à plusieurs clients d'afficher facilement les données du message). Nous appelons l'acte de stocker un nouveau message "publication", et nous fournissons une méthode pratique pour cela à Base._publish. Fondamentalement, tout ce que vous avez à faire est de remplir les blancs ici, assurez-vous que autant d'informations que possible sont remplies dans autant de colonnes que possible. Les arguments possibles pour _publish sont définis dans le schéma , et vous pouvez à nouveau vous référer aux plugins existants pour voir comment ils le font.

Une fois que vous êtes arrivé jusqu'ici, vous devriez en avoir assez pour pouvoir le tester. Nous fournissons quelques outils dans le toolsrépertoire pour faciliter l'exécution de votre code à partir de l'arborescence source, vous n'avez donc pas à l'installer sur le système chaque fois que vous souhaitez apporter une modification. Ce que vous devez faire est d'ouvrir un terminal, de cd à la racine de l'arborescence source et d'exécuter ./tools/debug_slave.py. Cela se connecte au DeeModel et affiche simplement tout ce qui lui arrive, de sorte que vous pouvez voir les messages apparaître en direct à mesure qu'ils entrent. Ensuite, dans un deuxième terminal, cd à la racine de l'arborescence source à nouveau, et exécutez ./tools/debug_live.py instagram receiveet qui déclenchera manuellement la méthode Instagram.receive et affichera un tas de sortie de débogage pour vous informer de ce qui se passe pendant son exécution (vous pouvez saupoudrer votre code d'appels àlog.debug("hi") si vous voulez voir encore plus de détails sur ce qui se passe).

Oh, et si vous lisez toujours, le plugin linkedin n'a pas encore atterri dans le coffre, mais vous pouvez toujours le consulter ici.

Si vous avez d'autres questions, je suis toujours en #gwibber sur freenode, et je pense également que la nouvelle base de code est beaucoup plus lisible et mieux documentée que tout ce que Gwibber a jamais eu, alors s'il vous plaît, lisez le code qui est là et il ne devrait pas '' t être trop difficile à apprendre par l'exemple. Facebook et Twitter sont les plus complets.

Merci de votre intérêt pour les amis!

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.