Autore di amici qui.
In effetti, come sospettavi, è necessario il supporto negli account online di Ubuntu prima che il supporto possa essere aggiunto agli amici. L'architettura degli amici dipende molto dall'UOA per fare tutte le autorizzazioni e gestire tutte le chiavi API per noi. Il mio esempio preferito è LinkedIn, perché finora è l'unico protocollo che ha contribuito alla community. Il plugin UOA è per lo più solo due file XML, oltre a un po 'di inganno autoconf, che assomiglia a questo. (scorri un po 'verso il basso per diff, che mostra chiaramente ogni singola cosa che doveva essere aggiunta affinché LinkedIn funzionasse).
Una volta fatto lo stesso per il protocollo, è necessario proporre l'unione con lp: account-plugins e fare in modo che Mardy li riveda, approvi e li unisca. Una volta che è a posto, puoi iniziare a scrivere il plugin friends, che sarà scritto in Python 3.
Ora, uno dei maggiori, importanti miglioramenti introdotti da Friends su Gwibber è l'uso delle sottoclassi. Nel codice Gwibber originale, assolutamente nulla è stato fatto con le sottoclassi, quindi ogni nuovo plug-in di protocollo era un enorme hackjob copia e incolla di vari bit di funzionalità di basso livello. Durante l'implementazione di Friends, ho fatto molta attenzione ad estrarre le funzionalità comuni in una superclasse, che può essere facilmente sottoclassata e modificata. La superclasse ha anche molti argomenti, a cui dovresti fare riferimento all'inizio. Sfortunatamente non abbiamo ancora creato sfinge per pubblicarli ovunque, quindi per ora dovrai solo leggere il codice.
Alcune cose importanti da tenere a mente è che il nome della tua classe deve corrispondere al "nome provider" utilizzato, senza distinzione tra maiuscole e minuscole. Quindi, se hai definito il nome del provider instagram, devi creare il file protocols/instagram.pye nominare la tua classe Python Instagram.
I due metodi più importanti che devi assolutamente implementare per consentire al tuo plugin di fare qualsiasi cosa, sono chiamati _whoamie receive. Questi sono ben documentati in base.py (link sopra), ma fondamentalmente il _whoamimetodo verrà chiamato automaticamente e passato in un dict che rappresenta un BLOB JSON già analizzato che ci è stato dato dal servizio quando è avvenuta l'autenticazione. Se sei fortunato, quel dict conterrà il tuo nome utente Instagram, ID utente e nome visualizzato, ma in caso contrario dovrai effettuare una chiamata API secondaria per raccogliere tali informazioni. Per Facebook._whoamiun esempio di protocollo che non ha fornito le informazioni in anticipo e che ha richiesto una chiamata API aggiuntiva all'interno del metodo, vedereTwitter._whoami per un esempio di protocollo che ci ha fornito tutti i dettagli di cui avevamo bisogno.
Successivamente, il receivemetodo è responsabile per effettuare la chiamata API che esegue il polling del servizio per nuovi messaggi. Questo è un po 'più in formato libero, perché ogni API REST è leggermente diversa, quindi dovresti fare riferimento ai documenti API del sito Web per capire cosa esattamente deve essere fatto qui. In http.py forniamo Uploadere Downloaderclassi che semplificano le chiamate all'API REST e possono anche analizzare le risposte del server JSON per te. È importante usare queste classi di convenienza perché si avvolgono libsoup, che è configurato per onorare le impostazioni del proxy GNOME (puoi ricordare quanto sia stato terribile il supporto proxy di Gwibber, e ora abbiamo risolto tutto).
Una volta ottenuta la risposta API dal server, è necessario memorizzarla nel nostro DeeModel (dove Gwibber ha utilizzato un BLOB JSON scaricato in un db sqlite per l'archiviazione dei messaggi, stiamo utilizzando un DeeModel, che è fondamentalmente solo un database che condivide lo stato su DBus, semplificando la visualizzazione semplice dei dati dei messaggi da parte di più client). Chiamiamo l'atto di memorizzare un nuovo messaggio "pubblicazione" e forniamo un metodo conveniente per esso a Base._publish. Fondamentalmente tutto ciò che devi fare è riempire gli spazi vuoti qui, assicurati che quante più informazioni possibili siano riempite in quante più colonne possibili. I possibili argomenti per _publish sono definiti nello schema e, di nuovo, puoi fare riferimento ai plugin esistenti per vedere come lo fanno.
Una volta arrivato così lontano, dovresti avere abbastanza per poterlo testare. Forniamo un paio di strumenti nella toolsdirectory per semplificare l'esecuzione del codice all'interno dell'albero dei sorgenti, quindi non è necessario installarlo nel sistema ogni volta che si desidera apportare una modifica. Quello che dovresti fare è aprire un terminale, cd alla radice dell'albero dei sorgenti ed eseguire ./tools/debug_slave.py. Ciò che fa è connettersi a DeeModel e visualizzare semplicemente tutto ciò che accade, in modo da poter vedere i messaggi che appaiono dal vivo quando arrivano. Quindi, in un secondo terminale, cd di nuovo alla radice dell'albero dei sorgenti, ed eseguire ./tools/debug_live.py instagram receivee che attiverà manualmente il metodo Instagram.receive e visualizzerà un sacco di output di debug per dirti cosa sta succedendo mentre viene eseguito (puoi cospargere il tuo codice con le chiamate alog.debug("hi") se vuoi vedere ancora più dettagli su ciò che accade).
Oh, e se stai ancora leggendo, il plugin di linkedin non è ancora arrivato nel bagagliaio, ma puoi ancora dare un'occhiata qui.
Se hai altre domande, sono sempre in #gwibber su freenode, e sento anche abbastanza fortemente che la nuova base di codice è molto più leggibile e meglio documentata di qualsiasi cosa abbia mai avuto Gwibber, quindi per favore leggi il codice che è lì e non dovrebbe ' essere troppo difficile da imparare con l'esempio. Facebook e Twitter sono i più completi.
Grazie per l'interesse per gli amici!