Autor dos amigos aqui.
De fato, como você suspeitava, o suporte é necessário nas contas on-line do Ubuntu para que o suporte possa ser adicionado aos Amigos. A arquitetura de amigos depende muito da UOA para fazer toda a autorização e gerenciar todas as chaves de API para nós. Meu exemplo favorito é o LinkedIn, porque até agora é o único protocolo que foi contribuído pela comunidade. O plug-in UOA é basicamente apenas dois arquivos XML, além de um pouco de truque autoconf. que se parece com isso. (rolar um pouco para o diff, que mostra claramente cada coisa que precisava ser adicionada para o LinkedIn funcionar).
Depois de ter feito o mesmo para o seu protocolo, você precisa propor a mesclagem contra lp: account-plugins e fazer com que o Mardy revise, aprove e mescle-os. Uma vez que isso esteja no lugar, você pode começar a escrever o plugin de amigos, que será escrito em Python 3.
Agora, uma das principais melhorias principais que o Friends introduz sobre o Gwibber é o uso de subclasses. No código Gwibber original, absolutamente nada foi feito com subclasses, então cada novo plugin de protocolo era um enorme copiar e colar o hackjob de vários bits de funcionalidade de baixo nível. Ao implementar Friends, tomei o cuidado de extrair a funcionalidade comum em uma superclasse, que pode ser facilmente subclassificada e modificada. A superclasse também tem bastante docstrings, a que você deve se referir ao começar. Infelizmente, ainda não instalamos o sphinx para publicá-los em nenhum lugar, então você terá que ler o código por enquanto.
Algumas coisas importantes que você deve ter em mente é que o nome da sua turma deve corresponder ao "nome da empresa" usado, sem diferenciação de maiúsculas e minúsculas. Portanto, se você definiu o nome de usuário como instagram , crie o arquivo protocols/instagram.py e nomeie sua classe Python Instagram .
Os dois métodos mais importantes que você precisa implementar para que o seu plug-in realmente faça alguma coisa são chamados de _whoami e receive . Estes são bem documentados em base.py (link acima), mas basicamente o método _whoami será chamado automaticamente e passado em um dict que representa um blob JSON já analisado que nos foi dado pelo serviço quando a autenticação aconteceu . Se você tiver sorte, o dicionário conterá seu nome de usuário, ID de usuário e nome de exibição do Instagram, mas, caso contrário, você precisará fazer uma chamada de API secundária para reunir essas informações. Por favor, veja Facebook._whoami para um exemplo de um protocolo que não forneceu as informações antecipadamente e exigiu uma chamada de API adicional de dentro do método, e veja Twitter._whoami para um exemplo de um protocolo que nos deu todos os detalhes que precisávamos logo de cara.
Em seguida, o método receive é responsável por fazer a chamada da API que pesquisa o serviço em busca de novas mensagens. Este é um pouco mais livre, porque cada REST API é um pouco diferente, então você deve consultar os documentos da API do site para descobrir o que exatamente precisa ser feito aqui. Em http.py, fornecemos as classes Uploader e Downloader que facilitam a criação de chamadas da API REST e podem até mesmo analisar as respostas do servidor JSON para você. É importante usar essas classes de conveniência porque elas envolvem libsoup , que é configurado para honrar as configurações de proxy do GNOME (você deve se lembrar de como o suporte de proxy do Gwibber sempre foi péssimo; bem, corrigimos tudo isso agora).
Depois de obter a resposta da API do servidor, você precisa armazená-la em nosso DeeModel (onde o Gwibber usou um JSON blob despejado em um db sqlite para armazenar suas mensagens, estamos usando um DeeModel, que é basicamente apenas um banco de dados que compartilha o estado no DBus, facilitando para vários clientes exibir os dados da mensagem facilmente). Nós chamamos o ato de armazenar uma nova mensagem "publishing", e nós fornecemos um método de conveniência para ela em Base._publish . Basicamente, tudo que você precisa fazer é preencher os espaços em branco, para garantir que o máximo de informações possível seja preenchido em quantas colunas forem possíveis. Os argumentos possíveis para _publish são definidos no esquema , e novamente você pode se referir aos plugins existentes para ver como eles fazem isso.
Uma vez que você chegou até aqui, você deve ter o suficiente para poder testá-lo.Fornecemos algumas ferramentas no diretório tools para facilitar a execução do código na árvore de origem, para que você não precise instalá-lo no sistema sempre que quiser fazer uma alteração. O que você deve fazer é abrir um terminal, cd para a raiz da árvore de origem e executar ./tools/debug_slave.py . O que isso faz é se conectar ao DeeModel, e apenas exibe tudo o que acontece com ele, então você pode ver as mensagens aparecendo ao vivo quando elas entram. Então, em um segundo terminal, vá para a raiz da árvore fonte novamente e execute ./tools/debug_live.py instagram receive e que acionará manualmente o método Instagram.receive e exibirá vários resultados de depuração para informá-lo sobre o que está acontecendo enquanto é executado (você pode espalhar seu código com chamadas para log.debug("hi") se quiser ver ainda mais detalhes sobre o que acontece).
Ah, e se você ainda estiver lendo, o plugin linkedin ainda não chegou ao tronco, mas você ainda pode dar uma olhada aqui.
Se você tiver outras perguntas, eu estou sempre no #gwibber no freenode, e também sinto strongmente que o novo codebase é muito mais legível e melhor documentado do que qualquer coisa que o Gwibber já teve, então leia o código que está lá e não deve ser muito difícil aprender pelo exemplo. Facebook e Twitter são os mais completos.
Obrigado pelo seu interesse em amigos!