Друзья автора здесь.
Действительно, как вы и подозревали, требуется поддержка в онлайн-аккаунтах Ubuntu, прежде чем ее можно будет добавить в Друзья. Архитектура друзей очень сильно зависит от UOA, чтобы выполнить всю авторизацию и управлять всеми ключами API для нас. Мой любимый пример - LinkedIn, потому что пока это единственный протокол, предоставленный сообществом. Плагин UOA состоит в основном из двух XML-файлов, плюс небольшая хитрость автоконфигурации, которая выглядит следующим образом. (прокрутите немного вниз для сравнения, которое ясно показывает каждую вещь, которую нужно было добавить для работы LinkedIn).
После того, как вы сделали то же самое для своего протокола, вам нужно предложить объединение с lp: account-plugins и заставить Mardy просмотреть, утвердить и объединить их. Как только это произойдет, вы можете начать писать плагин друзей, который будет написан на Python 3.
Теперь одна из главных, основных улучшений , что друзья вводят более Gwibber является использование подклассов. В исходном коде Gwibber абсолютно ничего не было сделано с подклассами, поэтому каждый новый плагин протокола был огромным хакджоком копирования и вставки различных битов низкоуровневой функциональности. При реализации Friends я очень старался извлечь общую функциональность в суперкласс, который можно легко разделить на подклассы и изменить. Суперкласс также имеет довольно много строк документации, на которые вы должны ссылаться при начале работы. К сожалению, мы еще не настроили sphinx, чтобы публиковать их где-либо еще, поэтому сейчас вам нужно просто прочитать код.
Следует помнить, что имя вашего класса должно соответствовать используемому «имени провайдера» без учета регистра. Таким образом, если вы определили имя провайдера instagram, то вам следует создать файл protocols/instagram.pyи назвать свой класс Python Instagram.
Два наиболее важных метода, которые вам абсолютно необходимо реализовать, чтобы плагин действительно что-то делал, называются _whoamiи receive. Они хорошо документированы в base.py (ссылка выше), но в основном _whoamiметод будет вызываться автоматически и передаваться в виде dict, представляющего уже проанализированный большой двоичный объект JSON, который был предоставлен нам службой, когда произошла аутентификация. Если вам повезет, этот дикт будет содержать ваше имя пользователя в Instagram, идентификатор пользователя и отображаемое имя, но если нет, вам нужно будет выполнить вторичный вызов API, чтобы собрать эту информацию. Посмотрите Facebook._whoamiна пример протокола, который не предоставил информацию заранее и требовал дополнительного вызова API изнутри метода, и посмотритеTwitter._whoami для примера протокола, который дал нам все детали, в которых мы нуждались сразу.
После этого receiveметод отвечает за выполнение вызова API, который опрашивает службу на наличие новых сообщений. Это немного более свободная форма, потому что каждый REST API немного отличается, поэтому вы должны обратиться к документации API веб-сайта, чтобы выяснить, что именно нужно сделать здесь. В http.py мы обеспечиваем Uploaderи Downloaderклассы , которые позволяют легко делать вызовы REST API, и даже разбор ответов JSON - сервер для вас. Важно использовать эти удобные классы, потому что они переносятся libsoup, что настроено на соблюдение настроек прокси-сервера GNOME (вы можете вспомнить, какой ужасной была поддержка прокси-серверов Gwibber, мы исправили все это сейчас).
Получив ответ API от сервера, вам нужно сохранить его в нашей DeeModel (где Gwibber использовал BLOB-объект JSON, выгруженный в базу данных sqlite для хранения ваших сообщений, мы используем DeeModel, который в основном является просто базой данных который разделяет состояние через DBus, что позволяет нескольким клиентам легко отображать данные сообщения). Мы называем акт хранения нового сообщения «публикацией», и мы предоставляем удобный метод для него по адресу Base._publish. По сути, все, что вам нужно сделать, это заполнить пробелы здесь, убедиться, что как можно больше информации заполняется как можно большим количеством столбцов. Возможные аргументы _publish определены в схеме , и снова вы можете обратиться к существующим плагинам, чтобы увидеть, как они это делают.
Как только вы доберетесь до этого места, у вас должно быть достаточно, чтобы иметь возможность проверить это. В toolsкаталоге есть несколько инструментов, которые упрощают запуск кода из дерева исходных текстов, поэтому вам не нужно устанавливать его в систему каждый раз, когда вы хотите внести изменения. Что вам нужно сделать, это открыть один терминал, перейдите к корню дерева исходных текстов и запустите ./tools/debug_slave.py. То , что это делает подключается к DeeModel, а просто отображает все , что происходит с ним, так что вы можете увидеть сообщения , появляющиеся в прямом эфире , как они приходят. Затем, во втором терминале, компакт - диск в корень дерева источника снова и запустить ./tools/debug_live.py instagram receiveи это вручную вызовет метод Instagram.receive и отобразит кучу отладочных выводов, чтобы рассказать вам о том, что происходит во время его выполнения (вы можете посыпать свой код вызовамиlog.debug("hi") если вы хотите увидеть еще больше подробностей о том, что происходит).
О, и если вы все еще читаете, плагин linkedin еще не попал в багажник, но вы все равно можете посмотреть его здесь.
Если у вас есть какие-либо вопросы, я всегда на #gwibber на freenode, и я также твердо уверен, что новая кодовая база гораздо более читабельна и лучше документирована, чем все, что когда-либо было у Gwibber, поэтому, пожалуйста, прочитайте код, который там есть, и он не должен Слишком сложно учиться на собственном примере. Facebook и Twitter являются наиболее полными.
Спасибо за ваш интерес к Друзьям!