>>Но конечно же, имеет смысл сделать демона индексации который правда должен откуда то получать сведения о "появляющихся или изменяющихся" файлах

> Ктоб спорил..

Серёжа, не мне Вам рассказывать, что это реализовано в Spotlight :) Больше того, демоны, отслеживающие изменения в файловой системе, есть и в GNU/Linux. Опять же, читаем про бигл и медузу и радуемся :)

Возможностей фридесктоповского D-BUS Вам мало? :)

> Возможностей фридесктоповского D-BUS Вам мало? :)

Не нашёл там ничего, связанного с поиском текста. По-моему это просто протокол обмена сообщениями.

> Я сейчас думаю начинать писать модуль ядра

прежде чем что-то делать, спроси у гугла - кто-нибудь сделал это до тебя

Именно он и есть :)

Возможно я не так Вас понял, но... обмениваться данными между почтовиком и, скажем, поисковиком -- не оно? :)

Оно :) Но нужен стандарт на формат этих сообщений, т.е. более высокого уровня, чем D-BUS.

нужно сделать что то типа такого в ядре:
существует файл /proc/indices ,
в который пишутся пути к файлам при

1) API вызов create
2) API вызов write (если bytes_to_write>SOME_NUMBER)

вот и всё. а демон читает этот файл постоянно, индексирует файл за файлом и удаляет из него имена уже проиндексиных файлов.

такая система не должна сильно сказаться на производительности и индексация будет незаметной и что немаловажно, постоянной и оперативной

А swish mtime проиндексированных файлов нигде не сохраняет?

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

http://baby.chg.ru/manual_harvest

2vm: это путь аналогичный тому, по которому ходил MS Indexing Service... Весьма тормозная штучка. Гугль имхо использует более правильный подход, а именно есть демон-паук, который переодически обходит дерево каталогов. Если дата модификации файла с момента последней индексации не изменилась, то он его пропускает, если изменилась - переиндексирует. Так же он переиндексирует все новые файлы. Приоритет у процесса этого демона - минимальный, то есть он работает только тогда, когда система ничем не занята. Да не дает "мгновенной индексации", но она и не нужна - сами подумайте, вы ведь точно знаете что вы там понаписали в последнем файле, так что задержка в несколько минут или даже часов не принципиальна.

приятно видеть здравые мысли... пусть даже и не часто :)))

Izvinite za otsutstviye russkih bukv.
Nu opyat' pro _avtomaticheskuyu_ indexatsiyu localnih resursov.
Ya vsegda vistupayu protiv (nu pust' auto-indexatsiya budet kak dopolnitelnaya ficha, no ne eto glavnoye chto nujno!).
Esli vi ischete resurs kotoriy escho ne trogali nikogda - mirovaya pautina - gorazdo bolee yomkiy resurs i veroyatnost' nayti imenno tam a ne na localnom diske.
Localniy je resurs doljen bit' indexirovan kluchevimi slovami "_znachimimi_ _dlya_ _vas_", razlichnimi dlya raznih ludey, na ih yazikah, otrajayuschiye _ih_, etih ludey assotsiatsii. Extension of _their_memory_, not all possible words extracted from the text. Hash/B-tree personalnih assotsiatsiy (slov) i linki na absolutniye puti. Ya eto ispolzuyu davno dlya sebya.

Anode

Может кто-нибудь сделает нормальный поиск для ЛОР?

Может кто-нибудь сделает нормальный поиск для ЛОР? А то столько спецов по этому вопросу выявилось...

2HellAngel: это просто ты на этот раз понял о чем речь...:) А так у меня обычно все мысли здравые, ну или скажем так - многие, только вот труднопонятные для начинающих. :)

2Harliff: самое смешное что насколько я помню ЛОРовский движек, не GPLed и даже не OpenSource...:)

> Если дата модификации файла с момента последней индексации не изменилась, то он его пропускает, если изменилась - переиндексирует.

Можно ещё при этом автоматически строить распределение каталогов по частоте изменения в них файлов и наведываться в первую очередь туда где файлы часто изменяются.

2anonymous_incognito: угу, тоько не забыть по дефолту исключить из поиска каталог $TEMP... :) А то донаведаешся...:)

>Опять ведь мелкософт догонять будете...:)

Угу. Как только они выпустят длиннорог два, где может мы увидим winfs...

>Меня тошнит от перла, мне НЕ НРАВИТСЯ этот язык.

А мне не очень нравятся регулярные выражения, потому что одно дело видеть, что ты хочешь, а другое дело думать как выгрызть это из потока. Но пользоваться ими удобнее, чем глазками и ручками все искать.

>новый подход стоит попытаться продвинуть

Продвинешь тут. MS до сих пор не может с html и css справиться. И пойдут все кто в лес, кто по дрова - вокруг стандарта и рядом, но только не по самому стандарту.

Хорошая мысль.

Кстати, а почему бы не индексировать налету, а просто писать куда-нить "изменения были там-то", чтобы индексатор все дерево не обходил?

>ЛОРовский движек, не GPLed и даже не OpenSource

Что RSS, что поиск к движку отношения не имеют.

Ili new 'cp' (copy) utility (nazoviom eyo 'cpi'):
$cpi -k "key1" -k "key2" file_to_save /mnt/korobochka/file
i zatem cherez otdelnuyu progu (kotoraya budet podgrujat' nujniy plug-in po mailcap ili po MIME ili po rasshireniyu (na rezultat uje), no vnachale pokajet spisok vseh resursov - kak google):
$get -k "key1"
ili luboy zapros kak v gugle.

Ili plugin dlya mozilla "Save As" - i srazu v korobochku (ne zabit' vvesti kluchi - kak-bi localniye "meta name="Keywords"").

Ili plugin dlya explorera, popup-uyuschego dialojku na copy resursa v repositoriy: "vvedi kluchi".


Anode

>> Кстати, а почему бы не индексировать налету, а просто писать куда-нить "изменения были там-то", чтобы индексатор все дерево не обходил?

я как раз про это и говорю.
мне кажется что "куда" это есть /proc каталог.
Как известно, в каталоге /proc/$process_id/fd лежат симболик линкс на открытые процессами файлы.
Как один из вариантов, можно не писать модуль ядра а сделать простой демон индексации, который будет смотреть эти файлы и в случае изменений, вызывать внешнюю программу индексации (которой может быть и swish-e c парсерами различных типов файлов)

Ошибка

...нет, я всё таки заблуждаюсь. Спроектировал UML модель и оказалась зависимость от машины, что несложно понять и без UML :)
Нельзя привязывать к определённой машине индексатор так как изменения файловой системы могут быть со стороны других машин. Итого имеем: подход гугла правильный. Нужен просто недосаждающий демон индексации с низким приоритетом который в свободное время индексирует систему (изменённые файлы).

А это правда, что гугль-десктоп хранит инфу обо всем, что есть на твоем компе? Пароли, файлы, ссылки, логи асек и ирок, и тп и тд? Может он еще и кредитные карточки запоминаети номера счетов?

А не жирно ли? Гугль - следующая империя-корпорация зла?

А любая поисковая система будет хранить всю подобную инфу. Так что либо ищем ручками, либо пользуем поисковики... Аккуратно ползуем. :)

2Irsi

Появилось пару мыслишек насчет файловой системы с хранением данных в потоках.

Чтобы обеспечить совместимость со старыми форматами, нужно просто их преобразовывать налету. Т.е. копируешь, например, mp3 с fat, а записывается он уже расчлененным =) тег отдельно, музыка отдельно. Для переноса снова на fat происходит обратная склейка. Для преобразования можно использовать разные всеми любимые в этой ветке perl-парсеры =) Некоторое замедление будет происходить только при работе с неродными файловыми системами.

Идея мне понравилась. В чем могут быть недостатки?

Недостатки будут очень простые и очевидные - положим xmms открывает такой расчлененый файл... и как оно это делает? Нужен будет парсер, который для устаревших прог собирает все в одну кучу, как они привыкли... Следовательно придется хранить некую DB с mime type и списком унаследованных программ-обработчиков, а ткже с сылкой на соответсвующих склеиваетлей. То есть для xmms mp3 склеиваем, а для new-xmms - нет... Гимор и изрядные тормоза короче.
Более правилный момент - не просто расчленять, а дублировать... но тогда возникают вопросы синхронизации метаданных в самом файле (в "старом" формате) и в потоках... Хотя ее имхо решить будет уже проще и с меншими затратами.

Естественно будут проблемы со старыми программами или новыми программами. Только нужно выбрать правильный путь вперед или назад.

Дублирование тоже не выход. Это увеличит размер занимаемого файла в 2-е плюс служебные данные. Если делать расчленение на потоки налету, то тормоза появятся уже у новых программ.

Все-таки подправить xmms для правильной работы с новой системой будет проще, а для старых программ для совместимости сделать прозрачное преобразование.

В любом случае нужно идти на какой-то компромисс и потерю в скорости в каких-то программах (старых или новых).

2Irsi

обычный поисковик не лазит по моему hdd, не читает мои логи, не смотрит ссылки куда я хожу и т.п.

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

На самом деле решение есть, не идеальное но... Вообщем надо иметь два API - старое, которое занимается сбором многопоточных файлов в однопоточный, с лазаньем в mime type db и т.д., и новое, которое такой фигней не занимется... Старое использовать только для совместимости и следовательно потеря скорости будет только у старых программ...

2petrosha: нда... тыб чтоль почитал про google desctop search... Оно как бы чисто локально работает и с инетом не общается...

2Irsi : нда... тыб чтоль установил google desctop search... Оно чисто локально _не_ работает... - пытается соединятся

2Irsi

а если есть инет?

К XML конвертам, в которые упакованы данные файлов я отношусь в принципе положительно, но это выдвигает ряд новых проблем, хотя основное достоинство такой схемы - универсальность парсеров. Мало этого, ничто не мешает подвязывать любую БД для таких файлов.

То есть структурная единица это XML файл со вшитой в него бинарной датой. Как всегда, пример:
<file>
<name> Star Wars 1 </name>
<year> 1979 </year>
...
...
...
<film frames=789345 frame_size=234> <!-- здесь у нас собственно сам файл начинается -->
<frame num=3427>
...
<subtitle>"I see you"</subtitle>
<video_bytes>
00 4f 43 90 09 etc.
</video_bytes>
<audio_bytes>
0d f4 30 23 etc.
</audio_bytes>
</frame>
...
<frame num=3428>
...
<subtitle> "" </subtitle>
<video_bytes>
</video_bytes>
<audio_bytes>
</audio_bytes>
</frame>
...
...
</film>

</file>

такая схема позволяет любому агенту "знать" достаточно о фильме что бы принимать решения в своём поведении. В то же время сложность в том что нет программ "готовых" на такое сотрудничество - поддержка таких форматов. Как вариант могло бы быть своеобразное "принудительное" встраивание парсера и индексатора (короче кода который в базу данных признаки упаковывает) в библиотеку загрузчика elf . То есть, в память приложение получит только сам старый файл (своеобразный режим совместимости пока агенты широко не распространятся).

То есть от нас нужна просто программа которая будет собирать релевантную мета-инфу о некоторых файлах и перестраивать эти файлы - своеобразный интеллигентный XML упаковщик, который инфу из сети собирает а так же реструктуризирует саму дату - делает её более полезной (разбивка по кадрам например)

>Нельзя привязывать к определённой машине индексатор так как изменения файловой системы могут быть со стороны других машин

Ментально что ли? Сижу я, а машина рядом файлы изменяет?

>Оно чисто локально _не_ работает... - пытается соединятся

Путаем в google panel?

A ya protiv izmeneniy originalnih failov.
Ya - za dopolnitelniy meta-file kotoriy hranit:
1)last time update
2)offset (bmesto tagov)

naprimer mne nujen ankor (ukazat' na 2 seruyu) filma. Ya vmesto porchi originalnogo moovie prosto postavlu nomer baita v text faile.
meta-file poteryan - no problem - original budet jit.

A uj obslujivayuschaya proga put' ischet tot byte.

Po mne meta informatsiya doljna bit' _dopolnitelnoy_ - ne lomat' starih sovmestimostey/formatov.
Kak stylesheets.

imho konechno

Anode

>>Нельзя привязывать к определённой машине индексатор так как изменения >>файловой системы могут быть со стороны других машин

>Ментально что ли? Сижу я, а машина рядом файлы изменяет?

у меня как локальные директории замаунтены сетевые ресурсы - виндозовая самба, и иногда nfs c ftp

2petrosha: хммм... аварии у МТУ не так часты, то есть можно считать что инет есть всегда и я не заметил попыток серча залезть в оный :)

спасибо, в этом и был вопрос.

:)

а есть гарантия, что их и не будет?

2petrosha: гарантий не дает даже господь бог и вообще существует только одно гарантированное событие - все мы рано или поздно здохнем.
Но мне кажется это маловероятным, в свете волны поднимающейся против spyware...