скрипты для ассоциативного индексирования архивов

Если код такой же как и объяснение, то уже стоит заняться рефакторингом.

а чего это такое то? с чем едят? Для каждого юзера типа slocate -u но с немного иным типом доступа?

Раньше была поговорка: изобретать велосипед. Сейчас: изобретать гугл ;)
Для каждого чела свой, говоришь? Хм, подумай хорошо на досуге. Однажды
уже люди построили Вавилонскую башню. До сих пор разгребают последствия ;)

а beagle разве не тоже самое делает?
http://www.gnome.org/projects/beagle/

Основная аппликация - это "personal Google";. Вопрос "надо или не надо" - для меня не стоит. Мне - надо давно, поэтому и делаю. Подозреваю, что и кому-то ещё, а скорее всего - многим. Пример: нет доступа к интернету из-за аварии или политики отдельной компании где ты что-то фиксишь - что, работа остановилась? Hint: всё своё ношу с собой. Раньше был CD или несколько, сейчас - диск в ноуте, но проблема уже найти нужное - за линейное время в десятках гиг (части архива). А хочется - за пару запросов. Раскладывание в диры - давно не работает, нужна произвольная группировка (граф, не дерево) ресурсов, с произвольной организацией групп над файлами из различных мест на дереве (включая и online-URL).

Выложенные же скрипты - это просто одна из 3 имплементаций scalable persistent hash (В начальной, прототипной реализации "personal Google" сделал 3 разных бекенда для персистент хэш: файлы, MySQL и берклиДБ - чтобы выбрать наиболее подходящее позже). Это просто подзадача основной аппликации: сделать сколь угодно большой персистент хэш (map) или индекс (не грузить весь индекс в память как одну структуру).

Первая из 3х пробных реализаций - как и сказал выше - может представлять интерес отдельно, в отрыве от основной аппликации (как general purpose parsistent hash), потому и запостил отдельно. В случае с файловой системой - сама фс (XFS/JFS) хранит имена файлов в B*tree, что автоматически даёт линейный доступ по слову, если слов - миллионы и больше.

>Для каждого юзера типа slocate -u но с немного иным типом доступа?
Slocate - индексирование файлов, мне нужно индексирование всего и вся.
Можно на это также смотреть как на большой (добавляемый в течение всей жизни букмарк.
Очень большой нash/map короче.
Ну можно ещё язык запросов накинуть - для удобства.

>beagle
Beagle использует mysql, Mono (Gnome) и делает авто-индексирование (поправьте если не так). Я хочу только _мои_ индексы, с моими приоритетами (порядок вывода результатов).

Спасибо за комменты, буду благодарен за любой инпут

Я давно понял что рассовывать ресурсы по одной иерархии - гиблое дело. Время find/grep и время жизни "сходятся" ;) что не есть масштабируемо. Пересмотр ресурсов второй раз (например по приходу домой с работы) - тоже плохо. Принцип должен быть один: увидел-сохранил+добавил ключ-забыл (почти как в военной авиации ;)

Время копирования тоже возрастает (скорость шин почти не меняется, а объёмы носителей и архивов так и будут 'переть' по Муру). Я называю это "кризисом болванок".
Короче выход - огромная файлопомойка с инкрементальными ежедневными добавлениями: только 'insert', no 'move' (в автогенерённых директориях по таймстампу например) а индекс - для реального доступа (единственное что остаётся). Нужна надёжнейщая имплементация хранящая мета-информацию для этой файлопомойки - накопления всей можно сказать жизни. Ведь терабайты не за горами, и надо думать о петабайтах :)

>Ведь терабайты не за горами, и надо думать о петабайтах

Василий, именно поэтому я и пользуюсь услугами индексаторов! У меня стоит поиск на локальном носителе. простой perl/python cgi с html лицом на localhost

кто-то сказал: "Everybody cares about his own staff first",
и я предполагаю что так же как все сегодня делают себе коллекции музыки и фильмов(зачем - ведь есть радио и видюшники? ;) , так же будут делать коллекции знаний, книг, кодов, прошлой переписки итд - всё доступно через единый интерфейс.

да можно пофантазировать.
Я где-то читал про наличие очков с жидкокристаллическим полупрозрачным экраном. Представляю такое расширение ассоциативной памяти: у меня в кармане маленькая клавиатурка в виде наладонника или перчатки - для ввода, а в очках - вывод в несколько строк. Я начинаю разговаривать, узнаю имя человека, затем делаю запрос ("get имя") - вижу результат. Потом - в прцессе разговора - делаю какие-то записи для себя. Да тривиально - телефон записАть ("put -k vasili -v 123123123"), без переписывания и разгребания почты вечером. ЗаписАл - забыл. Вспомнил - только когда надо ("get vasili"). Рефайнил запрос - если надо.

Насчёт уже существующих реализаций. Для наладонника - mysql не пойдёт ;)
А если к домашнему серверу нет доступа в момент сохранения? надо иметь возможность сохранить локально - а потом ссинхронизировать всё за раз.
Вот стандарт такой передачи хешей, стандарт самих записей - предлагаю обсудить.

2vm
поиск (парсенье всего и вся) каждый раз? а если петабайты?
потом я не хочу чтобы машина за меня индексировала то, что я не виделб не отметил, а следовательно для меня несуществующее, даже если оно - рядом. Автопоиск - другая, необходимая аппликация, больше для _пополнения_ знаний. Я хочу сделать доступ к _уже_виденным_ и отмеченным знаниям (retrieval).

Хотя можно и объединить эти две разные аппликации как опцию.

Вспоминаются слова Страуструпа - "теперь я не понимаю, как работает мой телефон". Дожили. Уже файловые системы, которые умнее людей, делают. :(

файловая система имеет иерархическую структуру.
я предлагаю расширение, чтобы оригинальное группирование не имело значение и не несло семантического смысла и могло представлять собой инкрементальные бекапы: 20050123, 20050124, а группирование шло по многим признакам:
put -k "<несколько_ключей>" -v <path_or_url_to_value>

пример:
put -k "ais indexing vasili vm Eldhenn" -v http://www.linux.org.ru/profile/Anode/view-message.jsp?msgid=775270

и этот букмарк будет и в категории "indexing" и в категории "ais" в категории vm а также Eldhenn.
В какую диру мне положить ресурс если раскладывать всё по ящичкам-коробочкам? софт-линки не предлагать.

потом через
$get vm
я получаю все _интересные_мне_ (и сохранённые) посты "vm", а не все возможные стринги "vm" встречающиеся в тексте онлайн ресурса ЛОР.
Здесь в процессе сохранения я создаю группу с семантическим смыслом ресурса для меня который пришёл в голову сразу-же (а следовательно он наиболее вероятный быть успешно вспомненным в далёком будущем, когда грянет старческий маразм;)

по поводу плохих комментов/объяснения:
"documentation - like sex: when it is good - it is really good, but when it is bad - it is better than nothing" (C)

если серьёзно - то укажите где плохо, помогите исправить. Буду только благодарен. За сим и запостил сюда.

>У меня стоит поиск на локальном носителе. простой perl/python cgi с html лицом на localhost

Ха... вспомнил про индексаторы с web-мордой

В 1998 в домене .mil (точного адреса уже не помню) болтался такой архив с какой-то ерундой ... дык помнится через дыру в админском скрипте этого индексатора мы с коллегами (через пачку анонимных прокси) минут за 15 поставили его раком, заставив индексировать ВСЁ начиная с "/" до чего он мог дотянутся со своими правами ;))) На той машине стояла правда соляра. К чести местного админа он снес этот индексатор нафиг уже к утру ;)

протокол существующих записей таков:

каждая категория сохранена в отдельном файле. Файл - текст.
стоки (отделённые \n) - записи. Каждая запись - отдельный ресурс. Типы ресурсов определяются так:

* первый "небелый" символ в строке '/' - значит ресурс - локальный и дан его абсолютный путь.

* начало "http://" "ftp://" итд - имеем on-line ресурс.

* # - коммент. Кстати комментарии удобно использовать для простых записей. Пример - высказывание или заметка. Чтобы не создавать отдельный файл для каждой такой мелочи - можно использовать и показывать в результирующем выводе комментарий (можно назвать это простой записью).

Если ресурс кончается '/' - это директория и надо показать содержимое, а в момент просмотра мы уже выберем что надо.
В ином случае - это какой-то ресурс и viewer его покажет - уже как последний это понимает (mime-types, mailcup итд). Мы не занимаемся viewer'ом.

категория доступна очень быстро, линейно.
Потом можно сделать "И" -над отдельными категориями (язык запросов), и это будет пропорционально количеству строк а количество ключей мало в запросе. То есть главное ограничение - не иметь очень больших групп, но это справедливо и в случае Гугла: миллион резельтатов не просмотреть и надо делать ключи - предложения.

Ну, естественно пробелы эскейпятся на "_" и другие неразрешённые в именах файлов символы легко заэнкодить простым encode/decode преобразованием. Можно конечно надёжный base64 но хочется оставить базу индексов всё же читаемой. Кто-то может вручную, через обычный редактор что-то подкорректировать.

да, пожалуй '/' мы уберём сразу.
Можно показывать только всё относительно htdocs и игнорировать символические линки - если есть.

спасибо ;)

>да, пожалуй '/' мы уберём сразу.

и не забудьте про /../../ и его вариации с %blah-blah-blah ;))

>и не забудьте про /../../ и его вариации
ok (это всё будет конечно относится к on-line версии).
А со скриптами локально можно индексировать уже сейчас (или использовать как записную книжку, браузеро-независимый букмарк и пр.
Если кто начнёт пользовать и/или соптимизирует фильтры, защитит от вводимых неправильных для файлов символов, сделает TCL/TK гую или иной дополнительный фронт-энд - будет классно. Я не говорю - про тест и баги.
и послал бы diff от первой пробной версии.
Я скриптами наверное не буду пока занимиться - попробую веб-интерфейс в нормальный вид привести (насколько будет позволять время).

спасибо

> пример:
> put -k "ais indexing vasili vm Eldhenn" -v
> http://www.linux.org.ru/profile/Anode/view-message.jsp?msgid=775270
[,,,]
> я получаю все _интересные_мне_ (и сохранённые) посты "vm", а не все
> возможные стринги "vm" встречающиеся в тексте онлайн ресурса ЛОР.

Хорошо. Первое замечание: никто не мешает искать подстроку 'vm (*)',
которая выловит посты твоего vm? Вообще я согласен, что 'vm' - слишком
малый и слишком неуникальный набор символов. Но ведь искать все посты
vm без других ключевых слов - мало полезное занятие, не правда ли?
Наверняка будет другое ключевое слово, которое и определит успех поиска.

Далее, смотри сразу какая проблема вылезает. А что, если ты захочешь
искать любые посты vm, но только не те, что есть на LOR? Может такое
быть? Может. К примеру LOR окончательно опопсился, и инфа с него
потеряла для тебя всякую актуальность. Но тут засада! Ты изначально
не создал категорию 'LOR' и не помечал сообщения соответственно.
Что будешь делать? Править руками?

А в запросе гугла я просто укажу:
"строка поиска" -site:www.linux.org.ru

Вывод какой отсюда? Разбивать массив информации по ключевым словам -
красивая, но мало продуктивная идея. Проблем от её реализации
значительно больше, чем пользы.

>никто не мешает искать подстроку 'vm (*)',
да, но это скорее опять задача поиска, а не задача букмарков/закладок.
конечно&#184; я сделаю поиск (через Гугл, yahoo, grep - локально, и другие инструменты), а вот результаты этого поиска - мне надо сохранить. И сохраню я их в хэше. То есть есть 2 поиска: 1)в неизвестном мне 2)в сохранённом мной и несущему какую-то ценность выраженную во введённых ключах.
две разные задачи.

Да даже допустим ты хорошо и быстро делаешь запросы. Но ведь Гугл и любой динамический ресурс меняется и завтра ты уже будешь иметь ту-же инфу не в первых строках, а возможно в милионных. Я не говорю что большинство старых букмарков которые я делал в 90-х - недоступны. А если бы я делал "safe as" или wget сразу же - то не потерял бы то что для меня было значимо (было просмотрено, проанализировано, то есть ненулевое время _уже_ потрачено и на основании моего представления, в моём энвиронменте имеет какое-то значение).

я не предлагаю ничего бить - наоборот: добавлять метаинформацию (пока - ключи).
Это для того же для чего и "key" meta tag в html.

> А в запросе гугла я просто укажу: "строка поиска" -site:www.linux.org.ru

ну опять Гугл. А завтра он решит что надо инфу продавать. Старую оставит, а новая, структурированная будет уже за бабки.
Нельзя ни на что полагаться, что от тебя напрямую не зависит и не контролируется.
Опять повторюсь: а интернет отрубили? Всё, трава не расти, профессиональную деятельность выполнять не сможем?
Я например все конфиги, примеры, учебники, переписку, куски кода и проекты итд итп (всё чего я коснулся, то есть значимо каким-то образом для меня) предпочитаю иметь всегда вне зависимости от кого-то ещё, сети итд.

Хочу повториться: не путать задачу
a)поиска в неизведанном (работа _ещё_не_ проделана, мозговые CPU-циклы _ещё_не_ потрачены), а неизведанным, необработанным может и скорее всего и есть тот самый тутор который у вас сохранён и вы в него всё время лазаете, но лазеете совсем по другой причине почему лазеет ваш сосед
с задачей
б)поиска в обдуманной уже вами информации, процессинг произведён (не зря же, ведь циклы уже не вернуть ;), имеет какую-то ценность (в проекции на ваши знания, опыт) и вам надо его быстро достать по ключам. Да во втором случае тоже поиск, но он гораздо более направленный (если у вас совсем память не отказала ;)

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

Я наверное не до конца понял идею. Итак, есть хранилище какио-то информации (разные тексты, в разных форматах, чертежи и прочая). Так? Теперь мы "придумываем", что кроме полнотекстового поиска, неплохо было бы сделать поиск по ключевым словам или аннотациям (атрибутивный, так сказать, поиск). Ну и что в этом нового? Все системы управления неструктурированным содержанием так работают. Тот же Documentum... лопатит очень быстро по миллионам (вообще говоря, есть хранилища на миллиарды, но это экстрим и требует железа определенного) объектов - оно и понятно, все метаданные в промышленной субд хранятся (Oracle, DB2, Sybase, MSSQL).

2macavity
ближе, но не совсем то.
Я для народу, для народу хочу, (и для себя разумеется) а не для энтерпрайза :)

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

никто и не претендует на новое - всё уже было когда-то ;)

Честно говоря, в начале я было тоже пошёл стандартно: mysql, jsp, ну а тогда и томкат туда надо, и стратс для MVC, а потом кто-то посоветует hibernate, там пойдут jboss с ejb итд итп как это модно ;)
И никто эту байду не будет устанавливать. Да даже если там mysql - это уже отвратит кого-то (на тех машинах где mysql уже есть). Для такой аппликации всё должно быть маленьким, embedded (поэтому для серверной части я впихнул jetty и sleepycat - максимум. Результат- несколько мегабайт без зависимостей которые можно просто копировать, иметь сколько угодно рабочих копий итд (для жавы конечно предполагается jvm, хотя и jre можно заэмбеддить - если старый - будет мег на 6 больше). Но лучше наверное переписАть на С.

Я не хочу заведомо мёртвый бесконечный и медленный проект. Задача проста и кажется можно поддержать огромные репозитории (и для фильмов-музыки в том числе) на много лет вперёд - очень простыми средствами (имхо).

Вы сами-то Documentum пользуетесь в повседневной жизни? Как храните почту (со многих компов за много лет), как всё находите в архивах, сколько итераций и времени это занимает? Я серьёзно - мне просто интересно, как лоровцы группируют архивы.

Мне как-то не светит для хранения архивов, почты итд покупать EMC (да был-бы он свободный). Я с одним emc работал: до сих пор содрагаюсь - как же можно простые вещи усложнить. (Ну оно и понятно - программистам надо-же что-то делать ;)

Как мне кажется, для интерфейса идеально надо написАть плагин в мозиллу и в эксплорер.
Для первого - изменить диаложку "Save as..", добавив строку "Keywords", а сохранять - в предопределённой дире (апп. рут) под автоматически сгенерённой по таймстампу дире. Правда я не уверен что та диаложка (XUL?) - может быть изменена/экстендена так просто. Кто-то знает внутренности мозиллы?
С эксплорером сложнее - против драг-н-дропа надо делать наверное то-же что делает SVN (перехватывать копирование в архивное поддерево, и показывать отдельную диаложку "введите ключи").
Это для юзера.
Потому что copy-paste пути или URI в индекс (что есть уже сейчас , например - через веб-интерфейс) будет напрягать.

что на это скажете?

> что на это скажете?

Надо в меню файл сделать свой пункт "Сохранить в хранилище" по выбору которого выкидывать карточку на заполнение атрибутов (частично можно ее заполнять автоматом). Просто и со вкусом. Аналогичным образом тот же Documentum встраивается в MS Office и другие пользовательские приложения.

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

s/emc/cms

2Anode: На самом деле, нет проблем организовать архив почты для одного человека. Все становится сложнее, когда вам надо сохранять неструктурированную информацию в масштабах организации. Вот тогда становится понятно, что просто хранить и давать доступ - это уде ЗАДАЧА, которую простенькими и маленькими средствами не решить. MySQL не прокатит из-за того, что он на сложных запросах медленно работает, а посик по атрибутам - это именно сложный запрос. А про масштабируемость своего архива вы подумали? А про распределенность? Или это уже "интерпрайз"? А клиент к вашему архиву удаленно сможет подцепиться? Вообщем, я вам очень настоятельно рекомендую, посмотреть на то как устроен Documentum внутри и понять почему он нак устроен. Что касается EMC, то у них сейчас есть Centera (полнофункциональная CAS, внутри которой, кстати, стоит проприоритарное ядро на линуксе) - для архивов неизменняемого содержания самое то, что доктор прописал. :->

2 macavity
спасибо за документум

(то же ведь одно всего слово-ключ, а уже как-то семантически стало значимо. Щас вот сохраню: $put -k "documentum cms" -v "ихний урл" ;)

>доступ - это уде ЗАДАЧА

так стандартными средствами можно попробовать. юзера-группы - на уровне файлов, SSL/TLS/HTTPS - и маппить на юзеров - групп в аппликации.
Чтобы велосипед не изобретать (столько секурити моделей развелось, а по сути - на каждом уровне - свой ACL) - использовать listfile PAM модуль.

>посик по атрибутам - это именно сложный запрос

лекарство: индексировать по всем колонкам, которые встречаются в 'where' клаузах ;)

>А про масштабируемость своего архива вы подумали? А про распределенность?
масштабируемость - самое главное. Я знаю людей имеющих уже терабайты архивов ;)
если под распределённостью имеется в виду - client-server - то да (не в скриптовой естественно версии;) За тем и жаву приплёл сюда. Если бы не веб-морда и определённая сложность - C. Там много причин.

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

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

Documentum не свободный, но очень открытый и писать под него можно на java/jsp и это намного легче чем писать с нуля. Вообще, вопрос стоит так: сколько стоит разработка своего решения (с реализацией всех необходимых фич и их тестированием) и сколько стоит закупка готовой платформы и написание/подгонка для нее клиента (если стандартный клиент не устраивает)? Сравнение этих двух сумм + понимание того, что на коленке систему для крупного предприятия написать можно только за существенно большое время.. короче все это учитывается и принимается решение. Потом задувыются на тему интеграционных проектов (насколько ваша система открыта и документированна для интеграции? у Documentum огромнейшее API к которому лигко пристыковаться - все интерфейсы написаны на java).

ps: А как вы будете в своем архиве реализовывать регламенты хранения (жизненные циклы) информации?

>> посик по атрибутам - это именно сложный запрос

> лекарство: индексировать по всем колонкам, которые встречаются в 'where' клаузах ;)

ОК, а теперь представим себе как это будет. У вас есть типы объектов (для письма один тип, для договора другой, для факс третий и т.п.) У каждого типа свой набо атрибутов. Естественно, что where может содержать ограничение на любую их комбинацию. Опа! Теперь мы берем и создаем еще 10 новых типов, ну может не совсем новых, а потомков от базовых. Опа! И какой у нас будет индекс, а как часто надо будет делать полный его ребилд? Свою СУБД писать не придется, случаем? :)

>Что касается EMC, то у них сейчас есть Centera (полнофункциональная CAS, внутри которой, кстати, стоит проприоритарное ядро на линуксе) - для архивов неизменняемого содержания самое то, что доктор прописал. :->

Вы наверное в документум работаете ;)

У меня тоже ядро стоит и даже не проприетарное :))) , которое я волен в любой момент поменять и пропатчить. И рейд стоит. И на https переключимся (пока да, только http - для отладки). Ну что ещё нужно? XFS должно хватить надолго ;)

Anode, напиши UIN своей аськи или мыло, хотелось бы объединить усилия в достижении общей (или хотя бы похожей) цели...

// fuzk

> А как вы будете в своем архиве реализовывать регламенты хранения (жизненные циклы) информации?

"хранить вечно". Или завещание: "исполнить dd if=/dev/random of=/dev/archive" :)

ну не хочу, не хочу я ни под кого писать. Я делаю это не для клиента, а _для_себя_ . Было бы почти "just for fun" - если бы в реале не хотелось навести порядок в файлопомойках.

как всё делается мне рассказывать не надо ;)
(про себя: ни-на-ви-жю)
hint: маркетоиды и деньги рулят, а не технологии. Последние обычно воруются ;)

> У меня тоже ядро стоит и даже не проприетарное :))) , которое я волен в любой момент поменять и пропатчить. И рейд стоит. И на https переключимся (пока да, только http - для отладки). Ну что ещё нужно? XFS должно хватить надолго ;)

А нужно вот что: вы сохраняете в архив документ, получаете квиток (как номерок гардеробе). Далее вы идете смотреть оперу (продолжаем аналогию), а по возвражении на ваш номерок вы получает не вашу норковую шубу, а телогрейку. Вот так работает архив на рэйде (он никак не гарантирует, что вы получаете то, что клали). А в системах CAS все несколько иначе: невозможно по своему квитку получить что-то не то, потому как квиток это хэш по всему файлу. И если вы потом положите этот же документ в этот архив второй или цатый раз, изменив лишь карточку свойств, то система не сохранит его повторно, а просто пропишет связь с карточкой уже существующего файла в архиве. Есть и другой прикол: гроается один из рейдовых дисков, что делать? Надо зеркалить по новой. А в Centera любой файл храниться в двух копиях, при этом каждая копия на своем узле. Если грохается узел, то его содержимое сразу же дублируется с других узлов еще раз так, чтобы ни один узел не содержал обе копии одного и того же файла. При этом вы можете выннимать узлы на "горячем" архиве.

> Как мне кажется, для интерфейса идеально надо написАть плагин в мозиллу

Может прежде чем писать, посмотреть на то, что уже написано?

https://addons.update.mozilla.org/extensions/moreinfo.php?application=firefox...

https://addons.update.mozilla.org/extensions/moreinfo.php?application=firefox...

vgavr at rogers dot gone (sorry, com ;)
или vasili at srcportal dot net

2 macavity
и что нового?
хотите квиток как вы это называете - сделайте MD5 (одна строка).
Насчёт положить второй-третий-дцатый раз - так это другая задача - это version control и я использую CVS для этого. А зачем переизобретать? Ну, SVN установите если считаете что проще для вас.

про узлы - так это rsync на удалённый компьютер периодически - мне этого достаточно
А что если архивы - это туча фильмов, тоже MD5 считать?
Я лучше буду делать chkdsk и rsync регулярно.

Ну не надо мне "горячих" архивов - я один!

>> Как мне кажется, для интерфейса идеально надо написАть плагин в мозиллу

> Может прежде чем писать, посмотреть на то, что уже написано?

> https://addons.update.mozilla.org/extensions/moreinfo.php?application=firefox...

> https://addons.update.mozilla.org/extensions/moreinfo.php?application=firefox...

Ну вот и славненько. :)

>https://addons.update.mozilla.org/extensions/moreinfo.php?application=firefox...
>https://addons.update.mozilla.org/extensions/moreinfo.php?application=firefox...

отлично. Премного благодарен за ссылки.

Вообще - это же не только из мозилы или IE. Надо индексировать _всё_ включая простые записи по ходу работы итд, которые не существуют в виде урлов пока ещё.

Ой (c)

Расширения, которые я хотел указать - Download Sort и ScrapBook.

да, но а где в тех плагинах вводятся сами ключи???
не, задача даже частично не решена :)

>Но ведь Гугл и любой динамический ресурс меняется и завтра ты уже будешь иметь ту-же инфу не в первых строках, а возможно в милионных

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

ну не могут агенты сами...
Что напишешь - то и будут делать. А как нам задать правила? - мы этого и сами не знаем, потому что алгоритма нет. Но это - отдельный разговор.

Как я говорил выше - я рассматриваю "поиск в необработанном мною" и "доступ к увиденному и сохранённому" - как 2 разных задачи. Я занимаюсь второй задачей. Твои агенты - это первая задача.

потом я видел сгенерённые индексы (перлом например) даже ограниченных, но больших архивов. Там количество ссылок таково (и соответственно - время чтобы что-то найти), что быстрее grep сделать.
Другая задача. Точка.
Вот уже обработанные и осознанные мной данные, после агента - это уже _ценность_ для меня и их надо куда-то положить. И быстро достать используя тот ключ, под которым положили. Для меня - один, а для тебя - это будет совсем другая ассоциация (и соответственно - ключ).
То есть аппликация и индекс - персональные, личные. На один и тот-же архив - для каждого члена семьи - свой индекс.

почем трава?

> файловая система имеет иерархическую структуру.

AFAIK, файловая система UNIX не является деревом, ибо существуют хардлинки и симлинки.

В любом линуксе можно создать в домашнем каталоге /home/glenda/mail точно такую же структуру как в ящике Gmail, где все файлы будут храниться в одном каталоге, а во всех остальных будут стоять ссылки на них. (если хотите можно заменить "один каталог" на одну иерархию, например хронологическую)

Другое дело что большинство людей так не делает.

что интересно, эту аналогию юникс и gmail я услышал от человека работающего в microsoft.

согласен, переборщил с примером :) Но не сильно.
Почитайте как представляется солдат будущего, да и у лётчиков кажется что-то полупрозрачное пишется там.

Правило такое в IT: обычно корпоративные дорогие решения приходят в быт. Так было с компьютером, потом - с сетями, сейчас - с RAID хранилищами.

Логично предположить что и расширение памяти через полупрозрачные очки - не помешает :)
Тем более осуществить это уже сегодня можно (где-то проскааивало что типа M$ сделал подобные очки.
Не нравятся очки - вживляйте электроды - как один английский AI профессор, а если консерватор - будете пользовать наладонник или cell или что там будет.

> В любом линуксе можно создать в домашнем каталоге /home/glenda/mail точно такую же структуру как в ящике Gmail, где все файлы будут храниться в одном каталоге, а во всех остальных будут стоять ссылки на них. (если хотите можно заменить "один каталог" на одну иерархию, например хронологическую)

А не проще на каждый объект имет запись со всеми атрибутами в СУБД и искать там, где это _нужно_ делать? Потом, когда нашли, то все тривиально - просто вынимаем документ. Зачем изобретать не то, что велосипед, а колесо? Тем более, что изобретенное все равно будет хромать на все имплементированные в нем функции!

зы: В Штатах (и в Канаде, _кстати_, тоже!) сейчас треба ВСЮ почту хранить в архивах - чтоб те, кому надо, всегда могли проверить все, что надо. И под эту задачу (вернее под ее решение) народ готов платить большие деньги (закон, однака!)... Я что-то усомнился в альтруизме нашего друга, пишущего архив почты для себя. :->

А ещё можно камеры и микрофоны на голове носить а в рюкзаке компьютер, который в рилтайме всё снимает, слушает и анализирует.

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