Внедрение и перспективы Nepomuk
Содержание:
1. В чем идея?;
2. Использование Nepomuk;
3.Внедрение и перспективы Nepomuk (Вы читаете данный раздел).
Не так все радужно и с внедрением NEPOMUK в программы среды KDE. Я, признаться, очень заинтересовался, прочитав в одном материале про NEPOMUK, что вот как здорово: делаете примечания к тексту в PDF-файле, а потом находите их через NEPOMUK. И начал следить за перепиской между (теперь уже бывшим?) главой проекта Okular и Оливером Хайдбюхелем (Oliver Heidbuchel), приславшим патч для поддержки NEPOMUK. Опуская подробности, диалог в вольном пересказе примерно таков:
- Вот патч для внедрения в Okular виджета работы с NEPOMUK. Скриншот прилагается к коду. Есть некоторые трудности с масштабированием виджета, но Питер (ведущий проекта Dolphin) работает над этим.
- Я не уверен, что нам это действительно нужно... Не вижу, чем это лучше, чем окно «Файл — Свойства». Хорошо, что вы научились посылать патчи, теперь попробуйте убедить нас использовать их.
Чуть позже, диалог уже между разработчиками. Один другого спрашивает: «Ну что, разобрался с этим патчем?» Ответ: «Нет, все собираюсь его покрутить».
Еще позже - Оливер снова любопытствует о патче. А ему отвечают, что сейчас заморожены все нововведения (до выпуска KDE 4.4), так что сделайте себе заметку в календаре на февраль, чтобы напомнить нам о патче. Но с выходом KDE 4.4 ничего не изменилось. Теперь разработчики ждут, пока kdelibs для KDE 4.5 появится виджет KMetaDataWidget. И вообще, судя по переписке разработчиков с автором патча, разработчики не хотят ничего добавлять «извне» и тянут время.
Тем временем подобный или этот же патч лежит в недрах репозитория Linux-дистрибутива Mandriva, и его планируют применить в релизе 2010.1. Что тут скажешь? Народ хочет, народ делает, а upstream-разработчики отвечают на конкретные предложения: «Ok, didn't know that i'm a bit behind in all that sematic-y stuff», - ключевая фраза здесь переводится примерно как «Я немного не в курсе всех этих семантических штуковин».
В общем, существует как бы два уровня бытия NEPOMUK: радужные мечты и суровая действительность. В мечтах разработчиков - содержимое виджетов рабочего стола будет меняться в зависимости от текущей «задачи» (термин в рамках NEPOMUK). Переключаете задачу - на рабочем столе появляется свой набор файлов, связанных с задачей, а также контактов и тому подобного. В суровой действительности внедрение NEPOMUK идет с большим скрипом. Взять, к примеру, Amarok.
Казалось бы, NEPOMUK/Strigi тоже умеет индексировать музыкальные файлы - причем, как и Amarok, с помощью библиотеки чтения тегов Taglib. И что же? В исходниках Amarok уже есть код, где коллекция ведется через NEPOMUK, а не прежними средствами, однако этот код отключен. Разработчики ждут, когда части NEMOPUK, написанные на Java, будут воплощены в более быстром коде на C++. Сами же разработчики Amarok отмечают, что Java-компоненты NEMOPUK не такие уж медлительные, чтоб нельзя было пользоваться. Но ждут... Ждут и во многих других проектах, а ведь чем больше и активнее NEPOMUK начнут использовать, тем скорее сам NEPOMUK обретет стабильность и обрастет нужными другим разработчикам возможностями.
Что же мешает? Интерфейс API у NEPOMUK довольно продуманный. Кто бы отказался просто так от удобных функций работы с тегами, комментариями и тому подобным? Тогда что же? «Тормозные» Java-части. О чем именно идет речь? Для представления данных NEPOMUK использует движок Soprano (Qt/ C++). Для чтения-записи данных Soprano задействует бэкэнды. И вот для собственно хранения данных RDF (данные описательного вида, «субъект - предикат - объект»; например, «Прыг-скок» - «исполняет» - «Егор Летов») Soprano задействует движок Sesame2, написанный на Java. Это и есть, по мнению некоторых программистов, узкое место NEPOMUK.
Нашел свое применение Nepomuk и в мобильных системах. Более подробно мы рассмотрим данную тему в следующих статьях, ну а пока Вы можете найти вопросы и ответы про Android (http://roborobo.ru/) на страницах сайта roborobo.ru.
Существует второй RDF-бэкэнд, Redland, написанный уже на старом добром (а главное - быстром) Си - это Redland (http://librdf.org). Redland тоже используется в NEPOMUK - даже при наличии Sesame2. Наконец, третий бэкэнд - Virtuoso, аналог, альтернатива Sesame2. Virtuoso разрабатывается компанией OpenLink и имеет «открытую» версию (http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main).
И есть еще один минус NEPOMUK - относительная «прожорливость» в плане потребления памяти. С Sesame2 в роли бэкэнда он занимает в оперативной памяти около 130 Мб (с Virtuoso - около 80). Для современного компьютера это не так много, но для старой машины или для нетбука - уже те числа, когда пользователь задумывается, не отключить ли столь «тяжелый» сервис.
Впрочем, NEPOMUK - технология «на вырост», никто сейчас не собирается запускать его на мобильных телефонах, а ко времени широкого применения NEPOMUK его теперешняя «прожорливость» либо будет считаться нормой, либо будут какие-то новые, более скромные бэкэнды.
1. В чем идея?;
2. Использование Nepomuk;
3.
Не так все радужно и с внедрением NEPOMUK в программы среды KDE. Я, признаться, очень заинтересовался, прочитав в одном материале про NEPOMUK, что вот как здорово: делаете примечания к тексту в PDF-файле, а потом находите их через NEPOMUK. И начал следить за перепиской между (теперь уже бывшим?) главой проекта Okular и Оливером Хайдбюхелем (Oliver Heidbuchel), приславшим патч для поддержки NEPOMUK. Опуская подробности, диалог в вольном пересказе примерно таков:
- Вот патч для внедрения в Okular виджета работы с NEPOMUK. Скриншот прилагается к коду. Есть некоторые трудности с масштабированием виджета, но Питер (ведущий проекта Dolphin) работает над этим.
- Я не уверен, что нам это действительно нужно... Не вижу, чем это лучше, чем окно «Файл — Свойства». Хорошо, что вы научились посылать патчи, теперь попробуйте убедить нас использовать их.
Чуть позже, диалог уже между разработчиками. Один другого спрашивает: «Ну что, разобрался с этим патчем?» Ответ: «Нет, все собираюсь его покрутить».
Еще позже - Оливер снова любопытствует о патче. А ему отвечают, что сейчас заморожены все нововведения (до выпуска KDE 4.4), так что сделайте себе заметку в календаре на февраль, чтобы напомнить нам о патче. Но с выходом KDE 4.4 ничего не изменилось. Теперь разработчики ждут, пока kdelibs для KDE 4.5 появится виджет KMetaDataWidget. И вообще, судя по переписке разработчиков с автором патча, разработчики не хотят ничего добавлять «извне» и тянут время.
Тем временем подобный или этот же патч лежит в недрах репозитория Linux-дистрибутива Mandriva, и его планируют применить в релизе 2010.1. Что тут скажешь? Народ хочет, народ делает, а upstream-разработчики отвечают на конкретные предложения: «Ok, didn't know that i'm a bit behind in all that sematic-y stuff», - ключевая фраза здесь переводится примерно как «Я немного не в курсе всех этих семантических штуковин».
В общем, существует как бы два уровня бытия NEPOMUK: радужные мечты и суровая действительность. В мечтах разработчиков - содержимое виджетов рабочего стола будет меняться в зависимости от текущей «задачи» (термин в рамках NEPOMUK). Переключаете задачу - на рабочем столе появляется свой набор файлов, связанных с задачей, а также контактов и тому подобного. В суровой действительности внедрение NEPOMUK идет с большим скрипом. Взять, к примеру, Amarok.
Казалось бы, NEPOMUK/Strigi тоже умеет индексировать музыкальные файлы - причем, как и Amarok, с помощью библиотеки чтения тегов Taglib. И что же? В исходниках Amarok уже есть код, где коллекция ведется через NEPOMUK, а не прежними средствами, однако этот код отключен. Разработчики ждут, когда части NEMOPUK, написанные на Java, будут воплощены в более быстром коде на C++. Сами же разработчики Amarok отмечают, что Java-компоненты NEMOPUK не такие уж медлительные, чтоб нельзя было пользоваться. Но ждут... Ждут и во многих других проектах, а ведь чем больше и активнее NEPOMUK начнут использовать, тем скорее сам NEPOMUK обретет стабильность и обрастет нужными другим разработчикам возможностями.
Что же мешает? Интерфейс API у NEPOMUK довольно продуманный. Кто бы отказался просто так от удобных функций работы с тегами, комментариями и тому подобным? Тогда что же? «Тормозные» Java-части. О чем именно идет речь? Для представления данных NEPOMUK использует движок Soprano (Qt/ C++). Для чтения-записи данных Soprano задействует бэкэнды. И вот для собственно хранения данных RDF (данные описательного вида, «субъект - предикат - объект»; например, «Прыг-скок» - «исполняет» - «Егор Летов») Soprano задействует движок Sesame2, написанный на Java. Это и есть, по мнению некоторых программистов, узкое место NEPOMUK.
Нашел свое применение Nepomuk и в мобильных системах. Более подробно мы рассмотрим данную тему в следующих статьях, ну а пока Вы можете найти вопросы и ответы про Android (http://roborobo.ru/) на страницах сайта roborobo.ru.
Существует второй RDF-бэкэнд, Redland, написанный уже на старом добром (а главное - быстром) Си - это Redland (http://librdf.org). Redland тоже используется в NEPOMUK - даже при наличии Sesame2. Наконец, третий бэкэнд - Virtuoso, аналог, альтернатива Sesame2. Virtuoso разрабатывается компанией OpenLink и имеет «открытую» версию (http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main).
И есть еще один минус NEPOMUK - относительная «прожорливость» в плане потребления памяти. С Sesame2 в роли бэкэнда он занимает в оперативной памяти около 130 Мб (с Virtuoso - около 80). Для современного компьютера это не так много, но для старой машины или для нетбука - уже те числа, когда пользователь задумывается, не отключить ли столь «тяжелый» сервис.
Впрочем, NEPOMUK - технология «на вырост», никто сейчас не собирается запускать его на мобильных телефонах, а ко времени широкого применения NEPOMUK его теперешняя «прожорливость» либо будет считаться нормой, либо будут какие-то новые, более скромные бэкэнды.
