Время от времени в холиварах про KDE и Akonadi разработчиков последнего часто пинают за то, что они заставляют пользователей устанавливать полновесную СУБД, вроде MySQL или PostgreSQL вместо легковесного Sqlite. Virtuoso, который используется начиная с KDE SC 4.4, многие также считают слишком тяжеловесным. Как говорят противники Akonadi, разработчики последнего отмели Sqlite без всяких видимых причин, используя аргументы вроде «мы не умеем работать ни с чем, кроме MySQL» и «не будем и всё». При этом, в частности, упоминается вот этот комментарий в рассылке debian-russian.

Действительно ли разработчики Akonadi даже не рассматривали Sqlite? На странице проекта в Techbase говорится об обратном:

Почему не используется sqlite?

Мы пытались. Правда. Он не очень хорошо обрабатывает параллельный доступ к данным, что в лучшем случае ведёт к медленной работе, но у нас также случались блокировки (deadlocks) и ошибки транзакций. Как только это будет исправлено в sqlite, изменить Akonadi для его использования не составит проблем

Об этом же писал один из разработчиков Akonadi в рассылку kmail-devel ещё в октябре 2006-го года. Лично мне кажется, что за прошедшие с того времени годы им уже банально надоело отвечать на вопросы об SQLite.

Собственно, в разделе часто задаваемых вопросов на сайте Sqlite пишется следующее:

Несколько процессов могут открывать одну и ту же базу данных одновременно. Несколько процессов могут совершать операции SELECT одновременно. Но только один процесс может модифицировать базу данных. [...] Если в вашем приложении часто возникает необходимость в параллельном доступе к базе, вам стоит рассмотреть возможность использования клиент-серверной СУБД.

Akonadi изначально предназначен для того, чтобы предоставлять доступ к данным (в том числе и на запись) нескольким приложениям одновременно, и sqlite просто не проектировался для таких задач.

Конечно, если речь идёт о мобильных системах, то требования к параллельному доступу не такие критичные, в то время как ограниченные ресурсы не позволяют отдать на откуп Virtuoso 80-100 мегабайт памяти. Существует проект мобильного порта Akonadi, в котором как раз и используется sqlite, но он, к сожалению, развивается довольно медленно — последнее изменение датировано июнем 2009-го года.

К выходу KDE SC 4.5 летом этого года планируется завершить портирование всех PIM-приложений (почта, календарь, заметки и т. д.) на Akonadi. Среди прочего, это облегчит поддержку различных groupware-серверов, поскольку реализовав один раз Akonadi-плагин, нет необходимости даже вносить изменения в клиентские приложения на его основе.

Один из таких серверов, Open-Xchange, поддерживался ещё в приложениях KDE3, а теперь соответствующий плагин был создан и для Akonadi. Вот так, например, выглядит календарь, открытый в веб-интерфейсе Open-Xchange и этот же календарь, синхронизированный с KOrganizer:

В планах разработчиков Akonadi — избавиться от тяжеловесных зависимостей, и перейти на хранение данных в Virtuoso (который также используется в Nepomuk). Пока что это, к сожалению, невозможно, и по умолчанию используется MySQL. В то же время, у MySQL есть убеждённые противники, а потому в последние несколько месяцев была реализована возможность использования PostgreSQL. До недавнего времени это требовало ручной конфигурации PostgreSQL-сервера, но буквально сегодня Tobias «tokoe» Koenig добавил в trunk возможность использования сервера без предварительной настройки (как это сейчас реализовано для MySQL — Akonadi запускает отдельную копию PostgreSQL-сервера, и автоматически конфигурирует его на использование отдельного каталога с данными).

Для того, чтобы воспользоваться этой возможностью, необходимо скомпилировать свежий Akonadi из SVN, и придать $HOME/.config/akonadi/akonadiserverrc следующий вид:

[%General]
Driver=QPSQL

[QPSQL]
StartServer=true 

На некоторых дистрибутивах Akonadi может не найти исполняемый файл PostgreSQL-сервера, но в ближайшее время это будет исправлено.

Не пугайтесь акронимов в заголовке, просто Gary Greene начал работу над полной (по возможности) поддержкой Exchange для персонального информационного менеджера KDE, о чём и сообщает в своём блоге.
Основным мотивом послужило желание избавиться от необходимости иметь дело с Outlook и Entourage с одной стороны, и Evolution — с другой.

MAPI (Messaging Application Programming Interface) можно перевести как «прикладной программный интерфейс почты», и его поддержка — это опция номер один, если вы хотите, чтобы ваш почтовый клиент умел общаться на равных с сервером Microsoft Exchange.

MAPI на своём веку повидал множество изменений, и является трудной, активно маневрирующей целью для F/OSS-проектов, пытающихся обеспечить совместимость с этим протоколом. Одним из таких проектов является библиотека Openchange: её интеграцией с KDE PIM и будет заниматься Gary. Openchange, как реализации сервера Microsoft Exchange под управленим Unix, активно используется в Evolution, почтовом (и не только) приложении для среды GNOME.

Будет совсем не лишним, особенно для бизнес пользователей, иметь схожий уровень интеграции и в среде KDE.

Детали реализации поддержки MAPI

1. Основная цель — 100% паритет с Outlook в плане поддержки MAPI: Почта, Контакты, Календарь, Заметки, Журнал, Общие Папки, Задачи и Проекты.
2. Использование или неиспользование библиотеки openchange для реализации всего этого списка будет определяться на основе тестов и полноты функциональности.
3. Работа не будет вестись с нуля: за основу берется код, начатый в 2007 Brad Hards и доработанный Alan Alvares в рамках GSoC 2008.
4. Это будет Akonadi-ресурс, общающийся с Exchange-сервером на Extended MAPI/RPC, а с сессионным демоном Akonadi посредством D-Bus.
5. Где необходимо, будут задействоваться различные библиотеки проекта Samba4, чтобы мимикрировать под Active Directory-бэкенд Exchange-клиента, но по возможности, предпочтение будет отдаваться LDAP.

В мире информации необходимы как эффективные методы обмена ей, так и способы ее хранения. В каждой современной системе используется несколько различных СУБД, каждая из которых обладает своими достоинствами и была выбрана для удовлетворения определенных нужд. Однако, разнообразие в форматах порождает проблему совместимости и совместной работы с ресурсами. Чтобы решить проблему дублирования данных и несовместимости форматов, был начат проект Akonadi — четвертый из рассмотренных нами столпов KDE4.

Akonadi создавался как расширяемая система хранения персональных данных и метаданных для настольных компьютеров, обеспечивающая одновременный доступ для чтения, записи и создания запросов. Помимо этого, Akonadi включает несколько компонентов, таких как поиск и кэш, позволяющий получить быстрый доступ к данным, и уведомления об их изменении.

Читать далее »

В том же Commit-Digest разработчик Adenilson Cavalcanti Da Silva рассказывает об Akonadi-ресурсе для доступа к Google-контактам.

Доступ к Google-контактам в целом работает и полноценно поддерживаются следующие функции:

• получение/добавление/правка/удаление;
• диалог для пользовательского аккаунта;
• хранения пароля пользователя в KWallet;
• доступны поля: имя, email, телефон, должность, организация, адрес, заметки, фото;

Этот функционал протестирован и работает довольно стабильно, но помощь в тестировании со стороны пользователей не помешает: кто знает, сколько ещё багов скрывается в тёмных углах.

Код ресурса можно получить из секции playground по этому адресу, также понадобится собрать библиотеку libgcal, её можно взять отсюда: git://repo.or.cz/libgcal.git

Следующие возможности пока не готовы:

• календарь;
• оставшиеся поля в карточке контакта (множественные адреса, телефоны и т.д.);
• незакрытые TODO в исходниках;

Видео работы с ресурсом можно посмотреть на YouTube

Любые комментарии, замечания и патчи можно отправлять по адресу: cavalcantii-at-gmail-dot-com. В IRC-чате разработчик известен под ником Savago.

Как я уже и упоминал, среди разных компонентов KDE, которые должны хранить данные, есть некоторый разброд по поводу того, куда же эти самые данные складывать. В частности, Akonadi в его текущей инкарнации использует полновесный MySQL, а Nepomuk — Soprano, у которого есть несколько бэкэндов, самый удачный из которых написан на Java.

Самим разработчикам Nepomuk зависимость от JVM не нравилась, и недавно было объявлено о начале работ над бэкэндом, основанном на Virtuoso. Virtuoso — это SQL/RDF сервер, созданный компанией OpenLink Software, у которого есть открытая версия, выпущенная под GPL. Специально для разработчиков KDE программисты OpenLink добавили «легкий» режим, возможностей которого хватает для Nepomuk (в этом режиме Virtuoso отъедает около 80 мегабайт памяти, что по мнению разработчиков приемлемо. Если же вас и это не устраивает, то не забывайте, что Nepomuk в принципе является опциональным компонентом)

Кроме того, поскольку зависимость Akonadi от MySQL многих не устраивает, разработчики обсуждают возможность Akonadi также использовать Virtuoso для хранения данных. При этом будет гораздо проще реализовать возможность интеграции этих двух сервисов без необходимости дополнительной синхронизации

На OpenNet появилась ссылка на статью о текущем состоянии OpenChange — проекта, реализующего поддержку протокола MS Exchange. По словам разработчиков для выпуска первого полноценного релиза нужно еще около года работы.

Подсистема Akonadi, на которую планируется перевести весь набор приложений KDE PIM (в том числе KMail) к релизу KDE 4.3 через полгода, позволит прозрачно работать с OpenChange-ресурсами

Вышла новая версия Amarok 2. На фоне кучи багфиксов и мелких улучшений самым главным и самым критикуемым нововведением стал переход на использование в качестве хранилища данных MySQL-Embedded вместо SQLite.

Как объясняют разработчики, MySQL-Embedded позволяет достичь лучшей производительности при работе с большими коллекциями, а кроме того даёт возможность с лёгкостью использовать обычной MySQL-базы для совместного хранения базы.

Ведутся также работы над возможностью использованием Nepomuk и Strigi в качестве хранилища данных для Amarok. Nepomuk в свою очередь может хранить данные в разных форматах. О разных подсистемах KDE4 и используемых ими решениях для работы с данными можно прочитать здесь. Akonadi, к примеру, отказались как от SQLite, так и от MySQL-Embedded в пользу полноценного MySQL.

Напомню, что Akonadi — это система, организующая хранение персональных данных (письма, контакты, календари, в будущем — ещё и логи чатов. Strigi индексирует файлы на жёстком диске, а Nepomuk предоставляет доступ к тэгам, метаданным и связям между файлами.

Добавка Вынесу из комментариев:

Как-то они кто в лес кто по дрова. Могли бы организовать единый интерфейс к стораджу для всех приложений.

Ну общая тенденция именно такая. Все PIM-приложения будут использовать Akonadi. Все информация о тэгах используется через Nepomuk (в том числе в будущем, видимо, будет интеграция между Akonadi и Nepomuk для хранения информации о тэгах писем, например). Strigi также уже хранит данные в Nepomuk, а не собственной базе. Для Amarok’а — ведутся работы над бэк-эндом, который основан на использовании Strigi и Nepomuk, при чём за счёт использования Strigi он не будет требовать пересканирования коллекции. С другой стороны этот бэкэнд оказывается менее производительный, чем MySQL-бэкэнд

Почему для Akonadi необходимо вводить отдельную обработку ошибок?

Сервисом Akonadi будут пользоваться различные приложения (KMail, Mailody, апплеты Plasma и т. д.). То есть как таковой владелец процесса Akonadi внутри KDE будет отсутствовать. К тому же, Akonadi будет являться кроссплатформенным и кроссдесктопным сервисом, а значит, ему необходима независимая обработка ошибок.

На недавней встрече в Берлине были согласованы детали разработки нового обработчика ошибок, и вот как он будет выглядеть:

Простите, я рыдаю, и не могу это дальше переводить