Sebastian Trueg рассказывает о ходе разработки проекта Nepomuk в 2009 году.

Virtuoso

Одно из важнейших изменений в Nepomuk — это, безусловно, новый механизм хранения данных. Ранее пользователям Nepomuk приходилось использовать sesame2 – бекэнд, основанный на технологиях JAVA и потребляющий довольно много памяти, или же Redland, который не может похвастаться хорошей производительностью и не имеет многих нужных разработчикам возможностей.

Поэтому год назад была начата работа над Virtuoso-бэкэндом. Сервер Virtuoso соотвествует всем требованиям разработчиков Nepomuk, и отлично при этом масштабируется. Программисты из компании OpenLink, создателя Virtuoso, не только добавили «лёгкий» режим работы сервера, но и помогли с отладкой и исправлением проблем, возникших в ходе написания бекэнда. Читать далее »

Время от времени в холиварах про 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-го года.

На страницах этого блога мы не раз упоминали видение разработчиков будущего «ориентированного на задачи» окружения. Идея заключается в том, что когда вы переходите от одного вида деятельности к другому, рабочее окружение должно перестраиваться под каждую задачу. Пока что это отражено в пользовательском интерфейсе исключительно в виде концепции activities (что до недавнего времени в русском переводе было «занятиями», но сейчас является «комнатами» — да простят меня переводчики, но «занятия» мне кажутся более подходящим словом). Сейчас занятия — это всего лишь группы виджетов, между которыми можно переключаться с помощью всеми любимого зум-интерфейса (или виджета переключения занятий), а с выходом Plasma Desktop 4.3 занятия стало возможным ассоциировать с виртуальными рабочими столами.

Что же сами разработчики хотят от занятий? Занятие может включать в себя группу окон различных приложений; файлы, ассоциированные с проектом; группы контактов и т.д. Идея в том, чтобы работая с одним занятием, вы как можно меньше отвлекались на другие — так что почтовый клиент будет отображать только письма, ассоциированные с занятием,  чат-клиент спрячет лишние контакты и комнаты, а браузер уберёт подальше вкладки с анекдотами и прочими вконтактами.

Конечно, это видение включает многое из того, что пока ещё не реализовано в приложениях KDE, однако немалая часть низкоуровневого кода для поддержки занятий уже написана. В частности, для KDE SC 4.4 реализована поддержка занятий в подсистеме управления метаданными Nepomuk, так что любое приложение может «поинтересоваться» у этой подсистемы, какое занятие сейчас активно (правда, в KDE SC 4.4 ни одно приложение этого пока ещё не делает).

Chani Armitage пишет, что примерный план реализации связанных с занятиями возможностей выглядит так:

• KDE SC 4.4: зум-интерфейс всё ещё присутствует, но единственная его уникальная возможность — перемещение виджетов между занятиями. Nepomuk может сообщать приложениям, какое занятие сейчас активно.

• KDE SC 4.5: KWin научится ассоциировать окна с занятиями и показывать их только при активации соответствующего занятия. Одно окно может быть ассоциировано с любым количеством занятий (по умолчанию новые окна показываются во всех занятиях). Вместо зум-интерфейса будет введён «менеджер занятий». Прощай, ручка слива cashew в углу экрана, мы будем скучать!

• KDE SC 4.6: KWin будет сохранять и восстанавливать сессии (т.е. состояние окон), связанные с занятиями. Приложения начнут предлагать возможности по отображению данных, специфичных для занятий. Возможны эксперименты по автоматическому назначению занятий для новых окон.

• KDE SC 4.7: ???

• KDE SC 4.8: Profit!

Как я уже и упоминал, среди разных компонентов 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 для хранения данных. При этом будет гораздо проще реализовать возможность интеграции этих двух сервисов без необходимости дополнительной синхронизации

Благодаря Nepomuk-сервису для KRunner (напомню, что эти сервисы так и называются — Runner), последний можно использовать не только для запуска программ, но и для поиска файлов через Nepomuk.

Ryan Bitanga модифицировал Nepomuk Runner, чтобы он мог предоставлять дополнительные возможности, использующиеся в QuickSand (альтернативый интерфейс KRunner), то есть возможность производить различные действия с найденными файлами:

Вышла новая версия 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-бэкэнд

Элементы обещанного контекстно-ориентированного окружения (когда аплеты и приложения подстраиваются под текущую задачу пользователя) грядут уже в KDE 4.2. Последняя заметка в блоге Аарона — как раз про контексты, действия, и то, как всё это сейчас начинает отражаться в Plasma и Nepomuk.

Также ещё в одной недавней заметке анонсируется утилита для тестирования DataEngine’ов и Service’ов.

Если PolishLinux время от времени делают визуальные обзоры KDE SVN, то KDE Commit Digest каждую неделю подводит итоги свежих изменений в одном абзаце текста. Что привлекло меня в последнем выпуске — за отчётный период (с 17 по 23 марта) — немалая часть изменений связана с интеграцией различных компонентов: в Gwenview и Dolphin работают над поддержкой Nepomuk, в digiKam аудио и видео теперь выводится через Phonon, в Amarok выбросили все движки, и оставили один Phonon, а в Plasma добавлено несколько апплетов, связанных с различными KDE-приложениями.

Следом за этим абзацем идут несколько статей от разработчиков, но об этом — в следующий раз.

PS. А ещё в Konqueror добавлено крайне полезное меню со списком закрытых табов

Открылся сайт проекта Nepomuk — системы управления метаданными для KDE4. Пока что эта система может быть больше интересна разработчикам, чем пользователям. В будущем Nepomuk будет интегрирован с другими системами KDE, что позволит предоставить универсальное средство поиска. Но идея Nepomuk не только в поиске, но и в отслеживании взаимосвязей между данными (к примеру, если вы получили файл по электронной почте, то связь этого файла с письмом не должна теряться).