Amigos del autor aquí.
De hecho, como sospechaba, se requiere soporte en las cuentas en línea de Ubuntu antes de que se pueda agregar soporte a Friends. La arquitectura de Friends depende en gran medida de UOA para hacer toda la autorización y administrar todas las claves API por nosotros. Mi ejemplo favorito es LinkedIn, porque hasta ahora es el único protocolo que fue contribuido por la comunidad. El complemento UOA es principalmente solo dos archivos XML, más un poco de truco de autoconfiguración, que se ve así. (desplácese hacia abajo un poco para ver el diff, que muestra claramente cada cosa que se debe agregar para que LinkedIn funcione).
Una vez que haya hecho lo mismo para su protocolo, debe proponer la fusión contra lp: account-plugins y hacer que Mardy los revise, apruebe y combine. Una vez que esté en su lugar, puede comenzar a escribir el complemento de amigos, que se escribirá en Python 3.
Ahora, una de las principales mejoras importantes que Friends presenta sobre Gwibber es el uso de subclases. En el código original de Gwibber, no se hizo absolutamente nada con las subclases, por lo que cada nuevo complemento de protocolo era un gran truco de copiar y pegar de varios bits de funcionalidad de bajo nivel. Al implementar Friends, tuve mucho cuidado de extraer la funcionalidad común en una superclase, que se puede subclasificar y modificar fácilmente. La superclase también tiene muchas cadenas de documentos, a las que debe referirse al comenzar. Desafortunadamente, todavía no hemos configurado sphinx para publicarlos en ningún lugar, por lo que solo tendrá que leer el código por ahora.
Algunas cosas importantes a tener en cuenta es que el nombre de su clase debe coincidir con el "nombre del proveedor" utilizado, sin distinción entre mayúsculas y minúsculas. Entonces, si definió el nombre del proveedor para ser instagram, entonces debe crear el archivo protocols/instagram.pyy nombrar su clase de Python Instagram.
Los dos métodos más importantes que debe implementar absolutamente para que su complemento realmente haga algo, se llaman _whoamiy receive. Estos están bien documentados en base.py (vinculado anteriormente), pero básicamente el _whoamimétodo se llamará automáticamente y se pasará en un dict que representa un blob JSON ya analizado que nos dio el servicio cuando ocurrió la autenticación. Si tiene suerte, ese dict contendrá su nombre de usuario de Instagram, ID de usuario y nombre para mostrar, pero si no, tendrá que hacer una llamada secundaria a la API para recopilar esa información. Vea Facebook._whoamiun ejemplo de un protocolo que no proporcionó la información por adelantado y requirió una llamada API adicional desde el método, y veaTwitter._whoami para un ejemplo de un protocolo que nos dio todos los detalles que necesitábamos desde el principio.
Posteriormente, el receivemétodo es responsable de realizar la llamada API que sondea el servicio en busca de nuevos mensajes. Este es un poco más de forma libre, porque cada API REST es ligeramente diferente, por lo que debe consultar los documentos de API del sitio web para averiguar qué es exactamente lo que se debe hacer aquí. En http.py proporcionamos Uploadery Downloaderclases que hacen que sea fácil de hacer llamadas a la API REST, y pueden incluso las respuestas del servidor JSON de análisis sintáctico para usted. Es importante usar estas clases de conveniencia porque se ajustan libsoup, que está configurado para cumplir con la configuración de proxy de GNOME (puede recordar lo terrible que siempre fue el soporte de proxy de Gwibber, bueno, hemos solucionado todo eso ahora).
Una vez que tenga la respuesta API del servidor, debe almacenarla en nuestro DeeModel (donde Gwibber usó un blob JSON volcado en un sqlite db para almacenar sus mensajes, usamos un DeeModel, que es básicamente solo una base de datos que comparte el estado en DBus, lo que facilita que varios clientes muestren los datos del mensaje fácilmente). Llamamos al acto de almacenar un nuevo mensaje "publicación", y proporcionamos un método conveniente para hacerlo en Base._publish. Básicamente, todo lo que tiene que hacer es completar los espacios en blanco aquí, asegúrese de que la mayor cantidad de información posible esté llena en tantas columnas como sea posible. Los posibles argumentos para _publish están definidos en el esquema , y nuevamente puede consultar los complementos existentes para ver cómo lo hacen.
Una vez que hayas llegado tan lejos, deberías tener suficiente para poder probarlo. Proporcionamos un par de herramientas en el toolsdirectorio para facilitar la ejecución de su código desde el árbol de origen, para que no tenga que instalarlo en el sistema cada vez que desee realizar un cambio. Lo que debe hacer es abrir una terminal, cd a la raíz del árbol de origen y ejecutar ./tools/debug_slave.py. Lo que hace es conectarse al DeeModel, y solo muestra todo lo que le sucede, para que pueda ver los mensajes que aparecen en vivo a medida que entran. Luego, en una segunda terminal, vuelva a la raíz del árbol de origen, y ejecute ./tools/debug_live.py instagram receivey eso activará manualmente el método Instagram.receive y mostrará un montón de resultados de depuración para informarle sobre lo que está sucediendo mientras se ejecuta (puede rociar su código con llamadas alog.debug("hi") si quieres ver aún más detalles sobre lo que sucede).
Ah, y si todavía estás leyendo, el complemento de linkedin aún no ha aterrizado en el tronco, pero aún puedes echarle un vistazo aquí.
Si tiene alguna otra pregunta, siempre estoy en #gwibber en freenode, y también creo firmemente que la nueva base de código es mucho más legible y está mejor documentada que cualquier cosa que Gwibber haya tenido, así que lea el código que está allí y no debería Ser demasiado difícil de aprender con el ejemplo. Facebook y Twitter son los más completos.
¡Gracias por tu interés en Friends!