Domanda Come aggiungere supporto per nuovi servizi agli amici?


Con la nuova app per gli amici in Ubuntu, mi è venuto in mente aggiungendo il supporto per Instagram nella timeline sarebbe bello. Ho anche pensato che potrei farmi una pugnalata, ma ho difficoltà a trovare documentazione.

Esiste una specifica che descrive ciò che è necessario da ciascun protocollo? Come funziona l'autenticazione? Il supporto dovrebbe essere aggiunto prima agli account ubuntu-online o c'è un modo per gli amici di registrare il nuovo protocollo?

È molto nuovo e ha un nome Google molto difficile, quindi qualsiasi suggerimento nella giusta direzione sarebbe apprezzato.


19
2018-04-10 17:17


origine


Questo è il meglio che ho potuto trovare per ora: bugs.launchpad.net/ubuntu/+source/friends/+bug/1156979 e code.launchpad.net/~robru/gwibber/friends MA sembra che tu possa usare qualunque cosa sia stata usata per Gwibber (?) - Rinzwind
Bene, il codice per i protocolli supportati sembra vivere in: bazaar.launchpad.net/~super-friends/friends/trunk/files/head:/... Ma quello che mi piacerebbe davvero vedere è una specifica che descrive capacità e così ... - andrewsomething
Sono ancora i primi giorni;) - Rinzwind
Qualcuno mi dia tumblr plz. - Khurshid Alam


risposte:


Autore di amici qui.

In effetti, come sospetti, è 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 è stato fornito dalla community. Il plugin UOA è per lo più solo due file XML, più un po 'di trucco di autoconf, che assomiglia a questo. (scorrere verso il basso per il diff, che mostra chiaramente ogni singola cosa che doveva essere aggiunta affinché LinkedIn funzioni).

Una volta che hai fatto lo stesso per il tuo protocollo, devi proporre l'unione con lp: account-plugins e ottenere Mardy per rivederli, approvarli e unirli. Una volta che è a posto, puoi iniziare a scrivere il plugin friends, che sarà scritto in Python 3.

Ora, uno dei maggiori, maggiore i miglioramenti che Friends introduce su Gwibber è l'uso di sottoclassi. Nel codice Gwibber originale, non veniva fatto assolutamente nulla con le sottoclassi, quindi ogni nuovo plug-in di protocollo era un enorme copia e incolla hackjob di vari bit di funzionalità di basso livello. Quando ho implementato Friends, ho avuto molta cura di estrarre la funzionalità comune in una superclasse, che può essere facilmente sottoclassata e modificata. La superclasse ha anche un sacco di docstrings, a cui dovresti fare riferimento quando inizi. Sfortunatamente non abbiamo impostato la sfinge per pubblicarli ancora da nessuna parte, quindi per ora dovrai solo leggere il codice.

Alcune cose importanti da tenere a mente è che il nome della classe deve corrispondere al "providername" utilizzato, caso-insensibile. Quindi se hai definito il providername essere instagram, quindi dovresti creare il file protocols/instagram.pye dai il nome alla tua classe Python Instagram.

Vengono chiamati i due metodi più importanti che devi assolutamente implementare affinché il tuo plugin possa effettivamente fare qualcosa _whoami e receive. Questi sono ben documentati in base.py (linkato sopra), ma fondamentalmente il _whoami il metodo verrà chiamato automaticamente e passato in un dict che rappresenta un blob JSON già analizzato che ci è stato fornito dal servizio quando è avvenuta l'autenticazione. Se sei fortunato, quel dattero conterrà il tuo nome utente Instagram, l'id utente e il nome visualizzato, ma in caso contrario dovrai effettuare una chiamata API secondaria per raccogliere tali informazioni. Perfavore guarda Facebook._whoamiper un esempio di un protocollo che non ha fornito le informazioni in primo piano e ha richiesto una chiamata API aggiuntiva all'interno del metodo e vedere Twitter._whoami per un esempio di un protocollo che ci ha fornito tutti i dettagli di cui avevamo bisogno fin dall'inizio.

Successivamente, il receive il metodo è responsabile per effettuare la chiamata API che esegue il polling del servizio per i nuovi messaggi. Questo è un po 'più libero, perché ogni API REST è leggermente diversa, quindi è necessario fare riferimento ai documenti API del sito Web per capire cosa esattamente deve essere fatto qui. In http.py forniamo Uploader e Downloader classi che semplificano l'esecuzione di chiamate API REST e possono persino analizzare le risposte del server JSON. È importante utilizzare queste classi di convenienza perché si avvolgono libsoup, che è configurato per onorare le impostazioni del proxy di GNOME (potresti ricordare quanto fosse terribile il supporto proxy di Gwibber era sempre, beh, abbiamo risolto tutto ora).

Una volta ottenuta la risposta API dal server, è necessario memorizzarla nel nostro DeeModel (dove Gwibber ha usato un blob JSON scaricato in un db sqlite per archiviare i messaggi, stiamo usando un DeeModel, che è fondamentalmente solo un database che condivide lo stato di DBus, rendendo facile per più client di visualizzare facilmente i dati del messaggio). Chiamiamo l'atto di memorizzare un nuovo messaggio "pubblicazione" e forniamo un metodo di convenienza per questo a Base._publish. Fondamentalmente tutto ciò che devi fare è compilare gli spazi vuoti qui, assicurarti che quante più informazioni possibili siano riempite nel maggior numero possibile di colonne. Gli argomenti possibili per _publish sono definito nello schemae di nuovo puoi fare riferimento ai plugin esistenti per vedere come lo fanno.

Una volta che sei arrivato così lontano, dovresti averne abbastanza per essere in grado di provarlo. Forniamo un paio di strumenti nel tools directory per semplificare l'esecuzione del codice all'interno dell'albero di origine, quindi non è necessario installarlo nel sistema ogni volta che si desidera apportare una modifica. Quello che dovresti fare è aprire un terminale, cd nella radice dell'albero dei sorgenti ed eseguirlo ./tools/debug_slave.py. Quello che fa è collegarsi a DeeModel, e mostra solo tutto ciò che accade ad esso, in modo da poter vedere i messaggi che appaiono dal vivo mentre entrano. Quindi, in un secondo terminale, di nuovo cd alla radice dell'albero dei sorgenti, ed eseguire ./tools/debug_live.py instagram receive e questo attiverà manualmente il metodo Instagram.receive e visualizzerà una serie di output di debug per dirti cosa sta succedendo mentre è in esecuzione (puoi cospargere il tuo codice con le chiamate a log.debug("hi") se vuoi vedere ancora più dettagli su cosa succede).

Oh, e se stai ancora leggendo, il plugin linkedin non è ancora arrivato nel bagagliaio, ma puoi comunque dare un'occhiata qui.

Se avete altre domande, sono sempre in #gwibber su freenode, e inoltre ritengo molto forte che il nuovo codebase sia molto più leggibile e meglio documentato di qualsiasi altro Gwibber abbia mai avuto, quindi per favore leggete il codice che è lì e non dovrebbe essere troppo difficile da imparare con l'esempio Facebook e Twitter sono i più completi.

Grazie per il tuo interesse per gli amici!


34
2018-04-11 17:50