В рамках проекта Poisk (http://sqlite.mobigroup.ru/src/wiki?name=poisk) подготовлена система полнотекстового поиска, подходящая как для индексации документов на десктопе, так и для организации системы поиска на web-сайте. Работа Poisk основана на встроенном в SQLite движке полнотекстового поиска FTS3+ICU. Поддерживается индексирование файлов, архивов и файлов в архивах, распознавание кодировки текстовых документах производится автоматически.

Архитектура проекта организована (http://sqlite.mobigroup.ru/src/wiki?name=poisk-arch) в классическом "Unix way", т.е. подразумевает связь компонентов через неименованные каналы (pipe), что позволяет интегрировать программу с любыми языками программирования и консольными утилитами. Загрузить исходные тексты и готовые пакеты для Debian GNU/Linux можно из репозитория http://mobigroup.ru/debian/ (http://mobigroup.ru/debian/pool-lenny/main/p/). Система распространяется в рамках лицензии GPLv3.

URL: http://sqlite.mobigroup.ru/src/wiki?name=poisk
Новость: http://www.opennet.me/opennews/art.shtml?num=25516

• Poisk - полнотекстовая система поиска на базе SQLite,87, 01:19 , 22-Фев-10
  • Poisk - полнотекстовая система поиска на базе SQLite,аноним, 05:36 , 22-Фев-10
    • Poisk - полнотекстовая система поиска на базе SQLite,ig0r, 10:46 , 22-Фев-10
      • Poisk - полнотекстовая система поиска на базе SQLite,develop7, 14:58 , 22-Фев-10
        • Poisk - полнотекстовая система поиска на базе SQLite,ig0r, 15:28 , 22-Фев-10
          • Poisk - полнотекстовая система поиска на базе SQLite,develop7, 15:47 , 22-Фев-10
            • Poisk - полнотекстовая система поиска на базе SQLite,Veter, 16:15 , 22-Фев-10
  • Poisk - полнотекстовая система поиска на базе SQLite,svchost, 19:55 , 22-Фев-10
• Poisk - полнотекстовая система поиска на базе SQLite,БездыХанный, 01:41 , 22-Фев-10

> Как видим, мы осознанно жертвуем половиной возможной производительности в обмен на гибкость и надежность.
> http://sqlite.mobigroup.ru/src/wiki?name=poisk-arch

ок. оставляем sphinx пока.

Аналогично.

> Как видим, "трудоемкость" операции учетверилась

Мда, архитекторы. Unix-way, вообще-то, даже близко не подразумевает связь через пайпы. Классическая (и единственно правильная на мой взгляд) схема - библиотека, над которой делают консольную утилиту. В другом софте используют библиотеку, в скриптах - утилиту. И не надо ничем жертвовать.

В общем, разберитесь что такое unix-way для начала, потом поймите что он не самоцель, потом переделайте архитектуру так чтобы ваша "гибкость" не давала двойного или четверного оверхеда. А каким боком вы прилепили сюда надежность я вообще не представляю.

«Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс» (c) http://ru.wikipedia.org/wiki/Философия_UNIX

UI ≠ архитектура, ок?

Описанные программы — обёртки над либами.

> UI ≠ архитектура, ок?

UI это user interface? если так то Вы не правильно поняли цитату, там речь идёт не о User interface, а о интерфейсе между программами и их взаимодействии, что и определяет архитектуру.

>> UI ≠ архитектура, ок?
>
>UI это user interface? если так то Вы не правильно поняли цитату, там речь идёт не о User interface, а о интерфейсе между программами и их взаимодействии, что и определяет архитектуру.

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

Ну вот скажите, как мне писать к этому поделию биндинги, м? Оборачивать exec()'и и парсить вывод? Спасибо, не нужно. Закапывайте.

А если головой подумать? Нужен биндинг - делай напрямую работу с базой данных, на SQL. Формат известен, пример реализации есть.

Многие успешные кроссплатформенные проекты жертвуют производительностью в обмен на гибкость, надежность и кроссплатформенность.

Какое нетривиальное название у системы поиска.