Как добавить поддержку новых сервисов в Друзья?

Друзья автора здесь.

Действительно, как вы и подозревали, требуется поддержка в онлайн-аккаунтах Ubuntu, прежде чем ее можно будет добавить в Друзья. Архитектура друзей очень сильно зависит от UOA, чтобы выполнить всю авторизацию и управлять всеми ключами API для нас. Мой любимый пример - LinkedIn, потому что пока это единственный протокол, предоставленный сообществом. Плагин UOA состоит в основном из двух файлов XML, плюс немного хитрости с автоконфекцией, которая выглядит следующим образом. (прокрутите немного вниз для различия, которое ясно показывает каждую вещь, которую нужно было добавить, чтобы LinkedIn работал).

После того, как вы сделали то же самое для своего протокола, вам нужно предложить объединение с lp: account-plugins и заставить Mardy просмотреть, одобрить и объединить их. Как только это произойдет, вы можете начать писать плагин друзей, который будет написан на Python 3.

Теперь, одним из главных, главных улучшений, которые Friends вводит поверх 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 и просто отображает все, что с ним происходит, так что вы можете видеть сообщения, появляющиеся вживую, по мере их поступления. Затем во втором терминале снова перейдите к корню дерева исходных текстов и запустите [ 1115], и это вручную вызовет метод Instagram.receive и отобразит кучу результатов отладки, чтобы рассказать вам о том, что происходит во время его выполнения (вы можете посыпать свой код вызовами log.debug("hi"), если вы хотите увидеть еще больше подробностей о что происходит).

О, и если вы все еще читаете, плагин linkedin еще не попал в багажник, но вы все равно можете посмотреть его здесь.

Если у вас есть какие-либо вопросы, я всегда на #gwibber на freenode, и я также твердо убежден, что новая кодовая база гораздо более читабельна и лучше документирована, чем все, что когда-либо было у Gwibber, поэтому, пожалуйста, прочитайте код, который есть и это не должно быть слишком сложно учиться на примере. Facebook и Twitter являются наиболее полными.

Спасибо за ваш интерес к Друзьям!