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

сначала по поводу ссылки. спасибо. После переделки жава-версии c с томката на jetty - не хочется запускать и мониторить ещё и jetty на сервере. Завершу - поставлю. Вы можете пока:
1) посмотреть скриншоты на http://sourceforge.net/project/screenshots.php?group_id=124759
2) посмотреть что делают скрипты с коммандной строки и представить что те-же "get" "put" работают через веб.
3) сгрузить старую жава-версию 0.3 с сорсфоржа
http://prdownloads.sourceforge.net/ais/is-0.3.zip?download
(там в качестве базы - берклиДБ а встроенный jetty запустится на 8080 порту) и запустить локально:
раззиповав (под лин или вин) запустить
a)$sh server (будучи в той дире)
(под виндой - дабл-щёлкнуть на server.bat)
б)открыть браузер на http://localhost:8080/is/
ввести в качестве ключа поиск на "java" - должны увидеть результаты. Но сами ресурсы-книги разумеется не доступны потому что я их под веб-рут не положил
в) сохранить через "put" ваши ключи.
не пробовать другие меню кроме get/put - всё равно не работают

по поводу RDF - его я знаю и даже хотел имплементировать, но всё равно ведь нужен хэш. Его я и предлагаю. Насчёт того что же цеплять на этот хэш. я буду спорить против xml - это отдельный разговор.

да, туй который на скриншотах на сорсфорже - это жава-вариант туя (ais-0.3 - версия) туя и опции там совсем другие. Жава-вариант туя запускается через ./is или is.bat и доступна естессно только в жава-версии проекта. Понятно что работает под win тоже и ей надо JVM

скрипт же версия (ais-scripts-0.4) запускается через
./get
./put
(или sh get - если исполнимый бит не поменян)
работает под unix или cygwin
(можно ./get -h)

и находится в отдельном пекедже. Ну и раз в 100 быстрее, так как не надо инициировать/открывать/закрывать беркли при одном запуске.

ха,

только вышел со слэшдота (ниже привожу полную статью по которой можете выйти на оригинальный доклад)

"механизмы поддержки персональных арихивов на протяжении жизни человека" определены как одно из 7 основных направлений стоящих перед IT на ближайшие 1-2 десятилетия по мнению британских учёных, специализирующиеся в компьютерных науках (British Computer Society)
http://www.infoworld.com/article/05/01/25/HNfuturechallenges_1.html?source=NL...

http://www.thebrain.com/lowbrow/default.htm The Brain, personal solution

Оказывается, жив курилка, и неплохо жив.

Небольшая самоцитата, когда-то посланная в овес.растет.
---------
ЭПИГРАФ
А мне вот тоже безфайловая файловая система мерещится :)
Ну нравится юзеру именовать кусок памяти, ладно, именуй.
А где это находится -- либо ты знаешь изнутри, либо тебе
это не надо знать вовсе.



В папке Мои Документы лежали:
 - связка ключей от офиса,
 - недожеванный шарик от бубльгаммы,
 - набросок текста нового гимна СССР,
 - список айпи-адресов сайта майкрософт.ком,
 - процарапанная лазером металлическая пластинка, с контурами тела,
 - несколько смятых купюр зеленого и желтого цвета,
 - забытый уволенным год назад сотрудником зонтик,
 - обрывок ссылки на какой-то сайт, начинающийся с www.goo(дальше оборвано)
 - стопка фихтенгольца, изрядно потрепанная,
 - стопка опрокинутая,
 - обжимка для витой пары и незакатанные губы,
 - два (2) кактуса в зеленом и синем пластиковых горшочках,
 - вид на темзу-реку с выплывающими стругами стеньки Абра(дальше
                                                            неразборчиво)
 - пыльный коврик для мыши, изрядно погрызенный вирусами,
 - репродукция известной картины "недопитое пиво"
 - четыре файла с броским именем документ1,
 - закомментированный файл desktop.ini,
 - обложка с толстой книги "дорога на эшафот"
 - настройки текущего принтера во флОриде,
 - неимоверной замызганности кружка с холодным кофе до краев,
 - прибитый гвоздем к стене каталога сиди "все квэйки"
 - раскрытый нотепад на фразе @net use
 - забытая начальником сводная ведомость на депремирование,
 - и счета за картиру за июль месяц позапрошлого года,
 - файл Мои Документы.рар внутри которого еще такой же и все остальное,
 - надпись, сделанная перочинным ножом: "Стесь небылВася"
 - несколько полупустых стержней,
 - две кляксы от олова и большое темное пятно канифоли,
 - неразберичто в кракозебрах, обведенное красным фломастером,
 и огромный кусок голубого неба с белыми облачками...

16.06.2004, 29 лунный день...       Дручин Сергей.

(Sir) * Марево -- это когда Марина варит суп, а он не получается...*

                                                     ©2005 Google

наверное хэш это хорошо. Но вот древовидная струтура более приемлема, да и удобней в обращении. И таки приживается тот интсрумент, в котором делаешь меньше телодвижений.

Поставил плагин к Огнелису -- ScrapBook, доволен по уши. ИМХО, для того чтобы сохранить страницу мне нужно делать минимум телодвижений. Не покидая при этом привычнйо среды. Удобно. Перебрасывается с машинуи на машику тоже довольно просто. Организовал все в папки. Получилось довольно удобно... Плюс есть поиск по папкам.

Пока мало нарыто, может со временем проявятся другие подводные камни, но пока крутится быстро.

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

интересно, я и не знал что делал конкурента брейна.
Делал я году в 99 на жаве 1.0 (ещё под NS3 и IE3-4) апплет для показа сколь угодно большого двунаправленного графа и хождению по нему
http://srcportal.net/screenshots/graph.gif
Поплатили мне тогда несколько месяцев и перестали, а затем проект медленно умер - видимо моему клиенту не удалось побить брейн.
Жалко - интересный был проект.
Тоже помню про букмарки-ассоциации говорилось - теперь я понимаю - откуда ветер дул ;)


А 29 лунный день - классно, напоминает деление животных на классы - было что-то такое или у Кэррола или эпиграф в какой-то книге по группам.

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

Хэш позволяет очень просто построить произвольные пересечения, которые можно представить графом.

Пример из жизни.
Сохраняете все свом проекты в дире "Проекты"
Сохраняете книгу по С в дире "С"
Сохраняете книгу по Линукс в дире "Линукс"
Куда будете сохранять книгу по программированию на С под Линукс?
А проект на С под Линукс?
итд итд.
бардак начнётся очень скоро.

А я кладу книгу по С - в диру arch/20041012
делая
put -k "C" -v "arch/20041012"

книгу по С под Линукс - в диру arch/20041013
не забыв
put -k "C Linux" -v "arch/20041013"

и последний проект в диру arch/20041014
put -k "C Linux projects" -v "arch/20041013"

в результате когда я как-бы открывая папочку "С" через
get "C"
получу все 3 вещи в ней

через
get "projects" получу обязательно тот самый проект

а
get "Linux"
возвратит экзактли 2 сохранённых (под этой категорией или если хотите - папочкой) результата.

У кого больше порядка?
А забыл я ключ (как и вы впрочем можете забыть диру) - посмотрю на список своими очами или сделаю find/grep и незабуду добавить клоюч - если в голову что-то новое придёт.
То-есть я _никогда_ не занимаюсь такими глупостями как разгребание файлопомойки и хочу забыть про команду "mv"

Я думаю люди к етому придут, но когда им M$ это предложит.

Чем мои ассоциации отличаются от ваших имён директорий?

Василий, вот еще две ссылки не по делу :))

http://hnb.sourceforge.net/

http://humane.sourceforge.net/home/

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

"Мы уже столько денег выкинули на Java, что это н е м о ж е т быть ошибкой!"

Я, пожалуй, стуканусь в твой мэйл, тоже есть идейки :) Кстати, в чем недостатки XML-подхода? Ты тут обронил, и стало интересно. Мне не для спора.

> А 29 лунный день - классно, напоминает деление животных на классы - было что-то такое или у Кэррола или эпиграф в какой-то книге по группам.

Так тебе только подпись понравилась? :)) Я привел это как раз как слегка накрашенный образ файлопомойки Мои Документы. Причем, практически с натуры. Правда, требует легкого напряжения в сером веществе для более полного кайфа :) Художественно передравно с натуры как раз в 29-й лунный день, никак не могу супротив правды :)

Еще прикол на эту же тему -- Safari (browser in Mac OS X) не имеет команды импорта закладок! Когда грабишь спец-страницу со всеми ссылками -- получаешь только названия ссылок, а не урлы. А дропнутые на флэшку букмарки не все нормально копируются с нее потом под линуксом :)

Резюме: Броузер, не умеющий сохранять закладки в плэйнтекст/хтмл-файл непригоден для серьезной работы с веб-ресурсами.

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

Большое спасибо за линки - любая инфа очень полезна.

>Мы уже столько денег выкинули на Java, что это н е м о ж е т быть ошибкой!
:)
это основа всех человеческих поступков. Проанализируйте свои;) Сначала мы делаем выбор, а потом подгоняем всё под него: "Это ну просто не могло не случиться", "зато это дало такой-то опыт", "у меня не было выбора" итд. Ну и как следствие - тоже самое в технологиях и бизнесе: "раз не можем конкурировать в одной области - значит мы просто специализируемся совсем в другом или делаем упор на другом" ;) итд. Ну что я банальности развожу...

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

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

xml - я не против. Я опишу позже.

> И таки приживается тот интсрумент, в котором делаешь меньше телодвижений.

Вот я и не пойму, почему форма представлений в виде древовидной структуры слева и содержимого справа никак не подохнет. Более неудобной для человека структуры придумать трудно (хотя вполне возможно :). А уж по затратам времени/сил/попаданию в крестики дерева/и_прокрутки_в_поисках_где_бы_это_все_нафиг_закрыть люди проводят лучшие дни своей молодости. Уберите примитивный поиск из редактора реестра офтопика, и попробуйте продуктивно поработать, если вы забыли какой-нить элемент из полного пути к нужной ветви/значению

> Потом, я бы не сбрасывал и проблему с банальными гармматичсекими ошибками :( Того же ключевого слова, или запроса....

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

xml.
сразу скажу что я его не боюсь и с ним работал (правда только из-под жавы).
и то что парсинг медленный - тоже не главный аргумент, так как можно не использовать DOM, а только сами колбеки в момент парсинга (есть очень маленькие невалидирующие парсеры, которые просто дёргают на открытие и закрытие каждого тага).

Я подхожу снизу. (Имплементация базы данных - может быть любая: plain текст, xml, RDB, gdbm или что угодно)
что самая частая операция? lookup.
любой запрос от юзера после пропарсения будет формой типа
A && B && ~C
и может быть приведён к нормальной форме.

То-есть нам надо делать лукап А, потом - В, потом C, объединить первые 2 и выкинуть все строки которые есть в C.

Это будет происходить в любой имплементации, правда?
А теперь, допустим мы имеем RDF: которые ещё не распарсенные. Я что на лукап буду парсить миллионы xml? Нет конечно, я должен иметь хэш на все keywords anyway. Вот я и сделал её вначале, чтоьы была масштабируемой. Теперь если есть хэш - можно уже подумать: как хранить метаинформацию. Выясняется что все пропертя тоже надо толкать в ту же хэш (опять - не парсить же сколь угодно большое количество текстов).

Кстати и в RDB тоже самое. всё на что я делаю запрос - надо индексировать. А на кой чёрт мне тогда база - если у меня всё уже есть в индексе?
Беркли ребята это поняли давно. Ведь gdbm/ndbm/sleepycat - это просто хэш.

Можно далее написать что xml - это не-для-human-being-формат, а скорее универсальная структура для машины, а человеку проще - строка-за-строкой, так как стек у человека маленький а cache - в среднем 7 объектов. Это если руками править.

А пропарсить на один '\n' - гораздо быстрее (нет интенсивных операций со стрингами - проверка только на один char).

awk/sed тулы, аналогов которым я не знаю с xml (чтобы вот так просто с командной строки сделать любую фильтрацию над любым xml)

и другие

но я не говорю что не надо RDF привинчивать.
просто не это - цель.

Обычно в компаниях - не так. То что кул и звучит громко - берётся в начале, а потом разгребается performance (или это сделать невозможно), так как тул взят неправильно.

вот поэтому - вначале anyway_нужная хэш, а имплементация - да хоть оракл.

> Резюме: Броузер, не умеющий сохранять закладки в плэйнтекст/хтмл-файл непригоден для серьезной работы с веб-ресурсами.

честно говоря, именно закладки меня и сподвигнули сделать что-то, так как я пользуюсь тучей браузеров включая IE.

Ктати, если комманд-лайн хэша возвращает только URL/paths - как это сейчас - то можно наверное сразу пайпить на мозиллу (я не пробовал, но может там в ней есть что-нить для автоматизации).
пока для веб-интерфейса надо сервер запускать. А текущая версия - работает только со слипи-котом (java gdb).

Я вот хочу на недельке (или в выходные) найти время - переделать на существующую plain-text-files-db, то что имеем в ais-scripts

>Для авторов поисковиков оказалось сюрпризом, что бОльшая часть поисковых запросов содержит единственное слово

вау! я и не знал этого. Но подозревал интуитивно ;)


насчёт инструмента (языка) и имплементации БД

я открыт писать на чём угодно: хоть на С, хоть на Аде , хоть на питоне (выучим быстро если надо). Но это должен быть _лучший_ инструмент (известный нам) для данной задачи на данный момент. Критерии оценки можно описать. самое главное - чтобы я им пользовался сам и везде - без больших инсталяций: c компов приятелей, придя к кому-то незнакомому (запомить букмарки которые он мне даст), с работы итд, на разных системах.

еще ссылка на подобный структурированный блокнотик -- www.treepad.com Когда очень активно его юзал. Довольно интересно. Однако быстро захотелось автоматизирвоать некоторые свои действия. Формат у него достаточно простой, пакетную обработку слепить можно доволно быстро. Но в том-то и дело что требовалось интерактивное восприятие.

Потом пришел к выводу, что интсрумент это далеко не все. Важна еще технология его применения. Круг задач которые он может решать. Как эти задачи решаются с его помощью быстро и эффективно.

У меня стоит сейчас проблема: это набор материала из Инета, его предварительное структурирование. Потом более глубокое с ним знакомство. Разделение по категориям, что-то отсеить. Сделать пометки, выделить интересные фрагменты. Эти фрагменты увязать между собой. И при этом не потеряв первоисточник. Возможность всегда к нему вернуться. Очень важна часто история получения/ нахождения того или иного материала.

Все это дополняется технологическими проблемами: работа на различных компьютерах/ средах; защита от потери; слияние накопленной информации, подготовленной в различных метсах/ различными людьми и т.д.

Вот и пытаюсь определить, решает ли предложенный вами подход мои проблемы? Как? В какой степени? К чему я веду -- нужно описание: а) решаю такой круг вопросов б) дедается это так-то (глазами/ руками пользователя)

Все это в принципе здесь размазано тонким слоем по дискуссии... Хотелось бы более четкое и концентрированное.

Вот...

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

В www.treepad.com не серьёзно следующее. Цитата:
# 1 Gb (= 1000 Mb) is the maximum total size of all images inside a TreePad 7.x .tpd database. For TreePad 6.x .hjt⁄.tpz files the maximum recommended size of all images inside one database is 80 Mb

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

> Как?
следующий сценарий. Браузите веб. Держите открытой GUI-фронтэнд нашего индексатора. Безусловно вы захотите дополнительные категории в тект-филдах формы. заполняете форму (расширенная версия "put"), сабмиттите домой. Потом открываете другую форму (расширенная - то-есть с дополнительными полями категорий - версия "get") и пишете "показать необработанное", "показать нарытое Петей" - о расширениях - позже *)

> В какой степени? а) решаю такой круг вопросов
пока я не вижу ограничений. Как говорится - "The sky is the limit". Если у нас граф и мы кладём в узлы что мы хотим и этот граф может быть сколь угодно большой а время доступа - менее секунды - то любая бизнес-логика - это просто добавление новых категорий и представление этих категорий под своими бирочками, окошечками, удобными и натуральными для восприятия.

>б) дедается это так-то (глазами/ руками пользователя)
можно и руками (TUI) и автоматически (агент кладёт для вас;) и через привычный и родной Гугловский интерфейс (именно поэтому я его изобразил в прототипе - см скриншоты - не надо народу переучиваться)

Имплементация.
Так как поддержание огромных (гиги, петабайты - в будущем) архивов (если исключить поддержку железа, процедуру зеркалирования, проверки дисков) это то-же самое что и поддержание большой базы букмарков (разница лишь в форме URI: локальный это файл или удалённый) то я не вижу разницы между вашими требованиями и ais аппликацией как она видится.
Так как поток информации продолжает поступать ко мне и сегодня (и от вас я получил несколько линков), а база уже существует и продолжает расти и я не хочу терять то что уже нарыл или разгребать что-то в будущем - я срочно сделал хоть какой-то интерфейс коммандной строки, который и с гуёй будет имхо в любом случае нужен и хоть плохо, но как-то работает уже сейчас. Быть может - будет развиваться параллельно с веб-версией (основной) для случаев:
1) когда невозможен GUI (работа на headless сервере), разные вспомогательные таски над базой как например чистка, восстановление после обсыпания диска итд).
2) для любителей командной строки
3) как дополнительный интерфейс (самый универсальный UNIX-way API;) к самомУ индексу (базе), на который можно накинуть любой GUI (типа TCL/TK) через вызовы или exec("command_line_get") итд.

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

Гуи. Ясно что необходим.
Из всех гуёв веб-интерфейс кажется самым универсальным.
Можно конечно native, но я не в силах один (да и не знаю win API) поддерживать все версии виндов + ещё и как-минимум одну ветку (tcl/tk) линукс гуя (не говоря ещё о 2: gtk, qt) а ещё есть мак и др.
Если не будет много энтузиастов (что само по себе недостаточно - надо ещё и найти компромисс;) - я могу осилить только один trunk-версию аппликации.
...пока сделаем прерывание обсуждения имплементации ГУИ и подойдём с другой стороны...

Веб-интерфейс нужен? Да, в любом случае. Это если доступ отовсюду на домашний секур сервак. Потом https - уже есть, ничего не надо изобретать.
Так если веб-интерфейс уже есть - вопрос: а нужен ли нейтив. Последний вопрос я не отметаю, просто к нему можно вернуться - если что - когда _уже_ будет веб-интерфейс.
Вопрос на чём писать серверную часть (CGIC, перл, пхп, питон или жава) для меня не стоит (хоть и уважаю другие имплементации) так как на жаве я делал и очень сложные проекты и на последней просто сделаю раз в 5 быстрее. версия ais-0.3 - всего 3 Мег, без беркли будет на мегу меньше, дык там и jetty, и изолированный от кода (меняемый) html через темплейты, и стартует сервер меньше секунды.
То-есть я сервер хочу впихнуть прозрачно и вся аппликация будет порядка нескольких мег (или +6M на встроенную JRE - если вообще ничего не хотите устанавливать). Я думаю, на сегодня - 10М без единой зависимости неплохо (всё как бы static-compiled).
...возвращаемся по прерыванию...понятно почему я выбрал жаву для первой версии?


*) Частная бизнес-логика (хотя ваш Use-Case наиболее типичен и мне нужно то-же самое) может быть добавляема в виде плагинов.
Пример. Допустим кто-то (например видео-магазин или частная коллекция фильмов) хочет иметь определённую форму-скрин для лёгкого введения только определённых полей как то Код фильма, Жанр, Артисты, Год, Страна итд. Это очень легко сделать. Так-же как и берклиДБ используется для реализации отношений (entity-relationships), хотя никаких таблиц там нет. А базы кастомеров в беркли хранят насколько я знаю и yahoo и гугл (см. у них на сайте). Это просто другая концепция - не через таблицы, колонки которых кладутся в хэши, а изначально хэши, которые имплементируют те-же relations любого вида имея любой длины записи справа.


может я пишу несколько сумбурно, сорри. Критикуйте.

Ещё следующая идея.
Куда движутся базы?
Та-же берклиДБ делает уже следующую версию но не с бинарным файлом для хранения хэша, а текстовыми (xml) файлами. То-есть они тоже поняли, что файловые системы типа XFS,JFS которые открыты - уже и без них надёжно имплементируют B*-tree внутри (18 thousand petabytes - мне хватит:)
почитайте
http://www.linuxgazette.com/issue55/florido.html

то-есть для сервера если там XFS кажется что вообще дерево балансировать не надо (Но естественно - надо эскейпить все недопустимые символы для имён файлов): Я делаю "pump()" - (в скрипте pump.sh) - разбрасывание в дерево как у солярки в "put" - чтобы поддержать другие FS.

о том почему я сделал не как у беркли - xml для метадаты - я сказал выше. Кстати, можно сравнить производительности в конце. И никто не мешает прикрутить xml в будущем, убрав строки (как предлагается сейчас).

>и пишете "показать необработанное", "показать нарытое Петей"

я конечно-же имел ввиду, что веб-форма будет иметь что-то типа checkbox или drop-down - в той, кастомизированной форме.
Внутренняя имплементация может иметь просто следующую категорию:
___internal_not-processed
___neritoye_Petey

и эти категории будут содержать (указывать) на соответствующие урлы.

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

Смотрю, что тема как-то быстро иссякла... Нечто подобное, поиск, каталогизация по ключевым словам реализовано на opennet.ru Особенно, мне понравилась идея с деревом ключевых слов. Также , хорошо было замечено по поводу ключевых слов. Не это ли вы делаете?

Я так и не понял, а как реализована задача сохранения в Хранилище материалов? Руками? Не сложно ль? Например, есть документация, лежит, скажем на флэшки... И что мне нужно сделать? Получается, что-то вроде:

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

И на сколько кого хватит????

Т.е. имеет место быть две различные задачи: 1) Помещение материала в хранилище 2) Поиск и извлечение нужного

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

А проблема на саммо деле актуальная.... И уже витает в воздухе...

>Нечто подобное, поиск, каталогизация по ключевым словам реализовано на opennet.ru Особенно, мне понравилась идея с деревом ключевых слов.

не то, не то...
Для хранения своих букмарков Вы тоже публичный он-лайн сайт используете? Я и не утверждаю что претендую на что-то технологически совершенно новое (всё уже где-то было), но вот такой специфической аппликации - которую я хочу нет. И с биглом - большое различие, и с десктопным гуглом. Различия как в цели программы, так и в мелочах, каждая из которых может быть критической (для life-time архивов, например, или для удобства пользования, или безопасности итд.). Если хотя-бы одной фичи нет даже в очень близкой аппликации (и её нельзя/сложно добавить самому) - то переписывать надо, а в данном случае даже близких аппликаций нет (опять же вы всё найдёте по кусочкам, чем конечно пользоваться не сможете).

потом - опять иерархия? от неё мы бежим!

>Также , хорошо было замечено по поводу ключевых слов.
где замечено конкретно? Что? (я просто не нашел - что Вы имеете в виду)

>Не это ли вы делаете?
другое, другое :)

>Руками? Не сложно ль?
да, сложно, потому и ищу способ делать легче. Но даже путь руками - _работает_ , без которого я уже не могу найти старые рксурсы, а следовательно он верен. Если ещё всё автоматизировать - будет идеально.

a)...б)... к сожалению пока только так. Надо ещё писАть плагины к мозилле, IE итд.

>Правильнее было сейчас говорить о создании протипа

это и есть прототип (если прочитаете версию - пре-альфа/альфа). И скрипты могут рассматриваться как прототип но и как инструменты поддержки базы (хотя для себя с линукса я могу использовать и только их, как если бы они были продакшен). Всё зависит от точки отсчёта/наблюдения ;) Считаю, что многое уже есть (может и не описано и подразумевается). Попробуйте хранить хотя бы букмарки. Увидите что иной путь уже трудно представить. (может быть завтра кто-то пропишет браузер-независимую прогу для их хранения, на основе например берклиДБ или RDB, но пока я не знаю такой готовой, мне подходящей. Да и в том даже случае попробую спорить о форме хранения, компактности, специализации аппликации и возможности использовать её для life-time архивов итд). Если-же кто-то напишет или покажет - то что мне надо, обязательно воспользуюсь (сорс обязателен - будем форкать, чтобы приспособить под описанные в этом треде задачи:)

предлагаю также посмотреть на аппликацию ещё с одной стороны (четвёртой?) - _неиерархическая_ сетевая файловая система.
Это разве не так? nfs/smb имеют недостатки, которых мы избавлены предоставляя доступ поверх https (пока это не реализовано конечно, только демо простейшей операци над http). Плохое направление?
Над любой нативной FS. враппер. Есть sftp, но он _иерархический_ .

Короче, есть еще множество и множество аспектов, которые можно обсуждать бесконечно. Лучше ещё что-то дописАть за это время.
(да, за выходные написАл версию plain-text ДБ из жавы - совместимую со скриптовым прототипом. беркли теперь не будет по-умолчанию для жавы. Думаю напмсать также 3 имплементацию на С - с той-же базой).

2anonymous

пришла ещё одна идея. Омениваемся базами знаний. Вы мне посылаете что вы "нарыли" по отдельно взятой теме, я - посылаю своё. В какой форме мы будем это делать сегодня (если и системы разные и устанавливать что-то большое Вы не захотите итд). Вопрос второй: сколько времени на объяснение что-где или написание комментариев - вам понадобится.

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

Я верю что в будущем люди не будут много писАть и тратить время впустую, посылая друг другу семантические сети. Web - очень близко, но нужна возможность лёгкого соединения узлов графа, без правки вручную всех "<a href=...>"
Я вот думаю - может сделать демку такой сети в контексте например курсов университета (что человеку выбрать, какие книги/ресурсы прочитать чтобы получить специальность).
Надо конечно на это время, силы и желание :)

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

Я привел как пример реализации концепции, которая мне показалась очень упохожей на Вашу.

У нас цели и основные методы во многом совпадают. Я также придерживаюсь взгляда, что многое нужно хранить локально, нужно сохранять мета информацию, объем накапливаемого растет. Что гораздо более практическую ценность составляют собственная организация хранения документов (ссылки, наборы тематичеких миникаталогов и т.д.). Каждый документ, который проходит через меня нужно как-то обработать, классифицировать...

Полнотекстовый поиск это не панацея и его практическая польза не так велика.... Я полностью с вами согласен, его можно и нужно рассматриввать как предварительный этап подбора материала.

> потом - опять иерархия? от неё мы бежим!

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

> да, сложно, потому и ищу способ делать легче.

Я сейчас вовсю гоняю ScrapBook. Проект очень активно развивается. Я даже для них перевод сделал. Правда, не знаю включат ли его в сборку...

Но по мне очень удобно. Для того чтобы сохранить страницу мне нужно секунды и минимум телодвижений. Все делается не покидая браузера. Могу хватануть как всю страницу так и только то что выделено. Удобно!

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

В принципе очень близко подошли к идеалу.

> Попробуйте хранить хотя бы букмарки. Увидите что иной путь уже трудно представить.

угу. Хотя меня Ява пугает. Помнится столько геморроя доставляла... так что у меня по большей части к ней антипатия... Но замечание верное. Брать-то откуда?

> Лучше ещё что-то дописАть за это время.

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

П.С. Блин, ну и язык у Вас.... боюсь, что в сегодняшнем моем довольно интенсивным ритмом полностью воспринять мысли мне не так-то легко...

ага, уже скачал версию 0.5 от 05-01-27... Буду пробовать...

> Омениваемся базами знаний.

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

Проблема с которой я сейчас сталкиваюсь -- это уменьшение "цифрового шума". Т.е. выкидывание из материалов ничего не значащих сведений...

Другая проблема -- это удаление (сигнализирование) наличия дубляжей...

не могу запустить java версию. На машине стоят две JRE 1.3.1 и 1.4.2 Почему-то видит только младшую версию... Обе версии рабочие, софт использует обе и вроде работает нормально.

Как заставить работать? Машина сейчас работает под ХР...

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

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

>ScrapBook

вот было-бы здорово добавить туда ключи, а последние - сохранять в нашей базе (с дополнительными внешними интерфейсами как то web).
Надеюсь добраться до scrapbook и до сорсов вскоре. Может и объединить усилия. Но ведь не только mozilla cуществует.

>Хотя меня Ява пугает. Помнится столько геморроя доставляла... так что у меня по большей части к ней антипатия

смотря как подходить. Если нужна помощь по тому как билдить - напишите. Там всё делает билд-скрипт. Я хотел и ant внутрь вставить - чтобы всё прозрачно, но не хотел раздувать (скажите - вставлю все jars внутрь) И тогда - только JVM - предполагается предустановленной.
А дальше -
while(true){ модифицируем, build, запускаем }
;)
ещё раз - скажите если надо док написать.

задача кажется в общем ясна. Спеки пусть менеджеры пишут - это можно делать бесконечно и бесполезно (так как при изменении в процессе - док надо переписывать). Потом ничто не связывает изменить что-то - если выяснится что надо. Да и бизнес-план для любителей нажиться неохота делать. Что можно - это почистоть README и docs.

>Да и хэши для него родные
не напоритесь на объём, когда хэш не будет влезать в память.
У жавы тоже хэши есть и в STL, но надо работать с очень большими хешами.
Если решите писать на Перле - то уж по крайней мере давайте использовать общий формат базы.

>язык
тут уж я извиняюсь - стараюсь объяснить как обсуждал бы очно, но не трачу много времени на проверку написанного.

>не могу запустить java версию. На машине стоят две JRE 1.3.1 и 1.4.2 Почему-то видит только младшую версию... Обе версии рабочие, софт использует обе и вроде работает нормально.

проще всего наверное переопределить PATH,
но правильнее (если не нужно непременно старая версия) - разустановить обе и установить снова более новую заново.
У сана в registry бардак - зачем они туда полезли - не пойму (ведь JVM можно просто копировать, если система одного типа).

версию 0.5 от 05-01-27... Буду пробовать...

это только лишь скрипт-версия (command-line).

жава-версия (старая, с берклиДБ) - пока на http://srcportal.net/ais-0.3.zip

новую - через часок поставлю на sourceforge (вложу туда и ant-библиотеки - чтобы ничего не надо было устанавливать кроме JVM)

поставил версию под номером 0.6
1. plain-text files - не берклиДБ
2. убраны бинарные виндовые cygwin библиотеки, которые я хотел использовать для автоматизации (~1M).
3. нет необходимости в установке ANT на машину (добавлены два скрипта-обёртки вызывающие ант): build.sh и build.bat
то есть для того чтобы сделать билд, просто имея корректно установленную java:
c:\>build.bat
или
$sh build.sh (или ./build.sh)

а так должно работать без билда, после раззиповки (по умолчанию положил классы):

1. командная строка
$./is -k "key" -v "value"
$./is -k "key"
(если нет value - имеем в виду 'get')
или просто get, put

2.ГУЯ (awt)
$./is -g

3. $ web
a) $./server
б) открыть браузер на http://localhost:8080/is/
(пользовать только 'get'/'put')

4. скриптовая версия - там-же (ais-scripts)
mysql и беркли пока отключены (хотя всё там) - plain-files are cooler.

под виндой тоже должно работать, но конечно - с .bat файлами (правда вместо "is --gui" используется gui.bat, можно дабл-кликом)

Решил подвести небольшой итог, сконцентрировать соображения, вот что получилось -- http://forth-j.narod.ru/note.htm Если полезут крякозябры -- поставить принудительно кодирвоку UTF-8. Лень пока разбираться, почему глюк выскочил...

> Спеки пусть менеджеры пишут - это можно делать бесконечно и бесполезно (так как при изменении в процессе - док надо переписывать).

Наверное, имеется в виду спецификации? Весь мой опыт говорит что это крайне нужная вещь. Надеюсь, что мои заметки заставят вас пересмотреть этот аспект. Я их написал в перерывах работы. И очевидно, чтобы понять мои взгляды совсем не нужно заниматься кодингом, при весьма и вестма спорной архитектру, которая выросла из расплывчатых и не аргументированных предпосылках.

Кстати, сдается мне что уж очень собираетесь повторить такую хорошо известную службу WAIS. Что в ней не так? Почему прекратили пользоваться? Может стоит предварительно изучить то что было сделано до, прежде чем проходить по тем же граблям?

> Да и бизнес-план для любителей нажиться неохота делать.

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

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

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

> Если решите писать на Перле - то уж по крайней мере давайте использовать общий формат базы.

Давайте. Но это спецификации, мнение ваше по которым ..... :(

> стараюсь объяснить как обсуждал бы очно,

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

>http://forth-j.narod.ru/note.htm
очень хорошо, согласен почти со всем. Исключения - дальше.


>разрешены ключ. слова с любыми символами (ну, за некоторым исключением)

и не только слова. Если юзеру стринг "kwjh!!ger<" что-то говорит - ради бога, меть документ им (если так легче вспомнить). То-есть не просто слова из словаря, а любые символьные последовательности. И можно без исключений (прозрачно для юзера энкодить/декодить). То-есть всё что он в состоянии набрать - всё и увидит.

UTF-8 поддерживается без проблем в жаве. ср-1251 - как-то неуниверсально, но не проблема.

<p> - вот я против именно этого разделителя. И не только потому что это 3 символа. Нестандартно. Всё-таки xml и "\n" - это 2 стандарта, каждый со своими недостатками, но стандарта. В том смысле, что сущ. скрипты и стандартные юниксовые утилиты из коробки (grep/awk/...) будут работать без изменений. Или тогда уж полный xml.
Если awk-подход - можно использовать "|" - если нужно дополнительные поля (ну, понятно, что эскейпить - если встречается в данных).
Но я пока задумывал индекс - как просто урлы, которые один в один можно чуть-ли не пайпить в браузер.
Потом если иконка - то не преобразовывать же её туда-обратно из бинарника в символы, и это некрасиво/неэффективно. Красивее всего её положить как есть, в служебную диру (как у CVS или svn), ну а уж раз последняя всё равно есть - и остальную дату - туда-же. Кстати - тогда даже и xml - для внутреннего формата можно туда-же пихнуть, я не против, не мешает самому индексу. Ведь поиск мы делаем только по ключам, а не мета-дате определённого документа.
То-есть метадата перечисленная как 1-5 - вся идёт в диру, например AIS. Ясно что если этой диры нет - все должно работать - это дополнительная инфа.

>подчеркну, что этим нужно будет заниматься, когда выдвинутая идея докажет свою работоспособность!!!!!
согласен 100%
поэтому и не думал пока о метадате, которая для моих задач была дополнительна.

насчёт объёмов - даже у меня одного они на порядок побольше. Я сделал грубый подсчёт файлов - только на ресурсном винте - это 365 тыс (там конечно и машков (на случай отключения, не дай Б-г;), и фильмы, куски кодов, отдельные записи). Если учесть полные бекапы систем - больше. Я знаю - люди хранят ещё больше. Потом вон на подходе войс-мейл, видео, фильмы. Корпорациям нужно ещё больше. То-есть любые ограничения - будут побиты: вопрос когда. Поэтому надо найти подход не имеющий физических ограничений. Чтобы наша аппликация подошла и для индексирования кусков ДНК, и даты накопленной ускорителями элементарных частиц ;)
Пусть очень простая элементарная операция (пока - просто хеш или индекс) - делается _очень_ хорошо. А прикрутить сверху что-то - будет прикладной задачей попроще, будь то индекс книг, фильмов, кластерная дата или днк.

> Весь мой опыт говорит что это крайне нужная вещь.

согласен. Я не умоляю преимуществ документации. Я - против документации ради неё самой, как способ отчётности итд. Документация необходима но вторична. Когда она ограничивает - плохо, помогает, дополняет - хорошо. В Вашем случае - пока помогает. Но многие часто её используют как замещение работы. Я этого боялся. Просто сильно доставало написание полных юз-кейсов, всех возможных UML диаграмм, особенно когда они неактуальны на следующий день. Но зато уже надо на уши всиаватьб, чтобы их придерживаться.

>WAIS
я ничего не знаю об её имплементации. Надо посмотреть.

>Давайте. Но это спецификации, мнение ваше по которым ..... :(
пока мы о формате не говорили. Предыдущий мой пост - касается этого. Не прочитав ваш док - мне не была понятна ваша задача. Теперь я понял и предлагаю подход CVS/svn (отдельная директория с мета-инфой). Жду комментариев.

>вольную транслитерация англоязычных терминов
попробую контролировать

есть альтернатива директории с мета-датой, прикрепляемой к ресурсу:
xml файл типа rdf. Но опять меня "корёжит" хранение иконок (если они так уж необходимы) в "[[CDATA" блоке (бинарный файл, вкодированный в символы) - это как картинки и файлы многие в оракле в виде блобов хранят : мало того что не посмотришь, ещё и гонять туда-обратно через жаву надо. Всё-таки бинарный файл должен быть как-есть, оригинальный, так как был сгружён и сохранён. Отсюда - лучше тогда его положить вместе с другими данными.

вопрос.
Вам очень нужна иконка? Где вы её (их) будуте в таких количествах брать для каждого ресурса?

У меня довольно большой личный архив (~500K файлов, ~1.5T байт) и я имею некоторый опыт индексирования некоторых частей своего архива (для внутреннего потребления) Тема меня живо интересует, и я осмелился сделать некоторые замечания по поводу заметок http://forth-j.narod.ru/note.htm 1. По поводу формата. - "Отвязать" иконки от индекса. Лучше заменить их дополнительными keywords. При имплементации GUI можно назначить иконки для особо важные keywords - любых. - Описание (аннотация). Поскольку его нельзя сгенерить автоматически, я уверен, для 99.99% всех документов это поле будет пустым. Может, убрать из формата? - Encoding. Я за UTF "from the beginning". (измучился кириллизацией в Linux'е. Каждая аппликация делает это по-своему. Мечтаю, чтобы все сорсы были переписаны в UTF, g++ это понимал, а также xterm'ы с grep'ами и sed'ами. Emacs уже понимает...) - В своих домашних индекс-подобных поделках я стараюсь избегать многострочных записей. Одна запись - одна строка, поля разделяю символом '|' (pipe). Это позволяет использовать grep, он работает быстро. Поиск в 100K записей egrep'ом на стареньком pentium-400 занимает секунду-две. 2. По поводу поиска. - я бы добавил возможность добавлять синонимы для keywords, это позволит искать по новым или изменившимся ключам без переиндексации основной базы (что будет все более трудоемко по мере ее роста - вне сомнения, экспоненциального) - Я бы приветствовал инкрементальный поиск (искать в найденном) - в дополнение к поиску по комбинации ключей. Поиск по комбинации keywords хорош для автоматических индексаторов типа Googla. В случае ручного индексирования для искомого документа некорые keywords могут быть не заданы в момент его индексирования ;)

классно!
со всем сказанном последним анонимусом - абсолютно согласен
(на 20050204;)

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

Если решите этим заниматься - можно попробовать переместится на сорсфорж (там зарегится надо для мейл-листов).

спасибо анонимусу с forth-j.narod.ru - за notes.

почему 8-битная кодировка?
Просто занимает места меньше, нежели UTF-8. Плюс приведенная в заметке аргументация. Потом, это формат _хранения_ индекса. Нужна другая кодировка, простой конвертацией текстового файла ее и получаем. Главное явно определенные моменты.

> Или тогда уж полный xml.

Я против xml. Его применеия -- это значительное усложние и ничем не оправдано. Владение вами, как разработчиком, некоторой библиотекой, позволяющей с ним работать -- не есть аргумент. Аргументы должны происходит от целей создания приложения, от особенностей его применения. Если мы добиваемся от формата легко его обработки и восприятия как человеком, так и программно, то, как показывает история UNIX, лучше и практичнее простых текстовых файлов еще не нашли способ.

> <p> - вот я против именно этого разделителя.

Аргументировано. Согласен. Но это должен быть символ, который:
- редко или вообще не встречается в текстах, вводимых пользователем
- желательно, воспроизводимым с клавиатуры.
В первоначальном варианте это был \b (код -- 007). Можем его использовать.

> Потом если иконка - то не преобразовывать же её туда-обратно

Упс... Глава "Что храним. Формат хранения", пункт 5 говорит, что храним _название_ _файла_ иконки! Которые лежат в специальной директории. И приведен пример. Пожалуйста, перечитайте документ.

Документация оказывается полезной, как вывод.

Зачем иконка? В консоли она -- лишняя, а если выводить в графике, очень даже полезна. Прочуствовано на собственном опыте. Удобство восприятия еще никто не отменял.

> Ведь поиск мы делаем только по ключам, а не мета-дате определённого документа

Поиск -- это всего лишь один из аспектов решения задачи. А остальные? Опять усложнение?

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

> поэтому и не думал пока о метадате, которая для моих задач была дополнительна.

Поэтому, предлагаю плясать от печки -- от задач, решение которых мы ищем или решение которых предлагаем. Тогда и станут понятно, что нужно и в какой степени.

> Я сделал грубый подсчёт файлов - только на ресурсном винте - это 365 тыс

А) пляшем от задач, верно?
Б) сколько времени вам потребуется чтобы из _в ручную_ проиндексировать? Можно сформулировать вопрос по другому, сколько в день вы отбираете документов, стоящих вашего внимания? (наколько, я помню, это была из основных, заявленных вами, задач)

> Корпорациям нужно ещё больше

Проблема с посстановкой задачи. В записках, в самом начале написал -- локальное хранение частной коллекции. Меня корпорации не интересуют. Как и их -- я и мои проблемы тоже.

> То-есть любые ограничения - будут побиты:

Самое большое и непреодолимое ограничение -- Человек.

Кстати, а можно поинтресеоваться вашей личной статистикой? Сколько времени используете индекс, сколько проиндексировали документов? Если не жалко можете выложить свой индекс (или его часть)? На пустом индексе сложно пробовать систему... а во время знакомства/опробования много не настучишь...

К вечеру выложу обновленную версию записок. (Адрес тот же).

2Anode:
1) я видел в ваших сриптах словарик англ. слов, для чего он?
2) я так и не понял как используется хэши? если у меня несколько ключевых слов в запросе? Можете словесно в общих чертах описать алгоритм поиска?
__________
Алексей
(Чтобы как-то внести ясность в нашу анонимность :))

Вот немножко о WAIS http://bolizm.ihep.su/Liber/Internet.Green/wais.html здесь его можно вживую пощупать http://www.ai.mit.edu/extra/the-net/wais.html

Советую также ознакомиться : http://www.citforum.ru/seminars/cis99/vest2.shtml

_________ Алексей

Пример индекса (у меня их несколько: каждый лежит сразу в корне соответствующего архивного диска) - возьмите на http://srcportal.net/index.tar.gz
(я и до скриптов этот индекс использовал и писал посредством vi или notepad или textedit с разных мест, rsync'ая или cvs на архивный диск вместе с новыми документами. Та система бекапов через rsync - достаточно отработана была - могу описать. Она и дала мысль что надо ещё упростить и предложить общественности).
раскройте tar. Если положите INDEX вместо существующего - то через
./get -k linux
например получите пару десятков путей/файлов/урлов.

1) я видел в ваших сриптах словарик англ. слов, для чего он?

> для unit (regression) теста (автоматическое заселение базы, предполагаются там-же различные выборочные проверки, но пока их нет). Простой авто-способ контроля качества продукта. Я его засасывал скриптом unit_test.sh и закидывал пары с произвольными значениями в базу: 62000 разных ключей дают представление о распределении, что ничего не сломано. Для этой же цели (отладки, теста) там test_words file. Чтобы не генерить генератором случайных чисел или не иметь только номера.
Сначала его же использовал и для теста жава-версии, но потом в жаве сделал отдельный unit-test (junit).
Запускается
$build.sh ut
или
$build.sh utgui
(но там мало проверок пока)

2) я так и не понял как используется хэши?

вся база - это хэш. Аппликацию как она есть сейчас можно назвать пока "реализацией персистент хэша". Берём что-то (из базы) по ключу и кладём по ключу. Что берём и кладём - зависти от аппликации. В нашем случае - видимо не просто урлы/пути_к_файлу_в_архиве но и набор записей (мета-данные 1-5).

>если у меня несколько ключевых слов в запросе? Можете словесно в общих чертах описать алгоритм поиска?

_пока_ - очень примитивно и по-разному в скриптовой и java-версии.

шел-скриптовая версия (ais/ais-scripts):
./get "a b"
даст логическое ИЛИ, то-есть все записи ключа а + все записи в, объединяя наборы результатов.

java-версия:
./get -k "a b"
вернёт записи ключа a_b как целого.

Естественно в обоих версиях должны поддерживаться оба подхода - именно поэтому в ГУИ я сделал чек-бокс "as sentence", а в скриптовой версии - флаг "-e". По-умолчанию будет конечно предполагаться что-то одно - в обоих версиях - одинаково.

Есть и третий вариант - логическое "И" - пока не имплементированное (когда два разных ключа направлены на один ресурс). Это реализовать несколько сложнее, так как надо поддерживать двунаправленный граф, то-есть каждый ресурс (value) должен знать (в обратную сторону) - какие ключи на него показывают. Но это для архива вряд-ли нужно (если юзер вспомнил и 'a' ключ и 'b' ключ - зачем ему держать в голове 2 вещи, когда можно скомбинировать в одну: "a_b")

Подзапрос-же (поиск внутри найденного) - это 4 путь и безусловно необходим.

>В первоначальном варианте это был \b (код -- 007). Можем его использовать.

я как-то упустил из виду что здесь же мы говорим о формате хранения мета-данных и разделителя для них, а это скорее - дополнительный файл, отдельный от INDEX и лежащий рядом с ресурсом. Разделитель для индекса который вы имеете - это другое. Индекс должен быть "аки стрела", он отделен.
Тогда для разделения описания (которое может содержать не только пробелы но и что угодно) и времени сохранения и других полей - можно вообще воспользоваться стандартным подходом multi-part MIME form (как разнородные данные как-то аттачменты, шлются в мейлах):
берётся произвольный стринг который вряд-ли встретится (ну можно вообще данные на него проверить, и сгенерить новый - если вдруг получили коллизию), и использовать этот стринг - как отдельную строку.
Ваш пример:


--i'm>>>>adelimiter123123123<<<<
описание бокумента блах-
блах-
блах
--i'm>>>>adelimiter123123123<<<<
http://ссылка.на/оригинальный.док
--i'm>>>>adelimiter123123123<<<<
ссылка на локальный док - необязательна, так как я и так здесь
--i'm>>>>adelimiter123123123<<<<
2005 02 04
--i'm>>>>adelimiter123123123<<<<
итд

поместил 6 скриншотов новой веб-версии
http://sourceforge.net/project/screenshots.php?group_id=124759
но саму версию выставлю когда сделаю итератор на Get и нормальную поддержку mysql плагина (наверное - в следующие выходные поработаю). Надо-бы что-то придумать - как между многими репозиториями скакать (например - private, public, intern_group).
Если есть идеи - пишите.

2 Anode

Самое простое решение - маркировать запись ключами типа

private,public,intern_group ;)

-o-

В общем, практически всю метадату можно вынести в ключи - чем больше,
тем лучше.

Есть уже Гуя.
Продолжение треда здесь
--> http://www.linux.org.ru/view-message.jsp?msgid=795605

Молоток!!! Придумал, что-то интересное... я пока скрипты еще не пробовал, но идея мне нравится, даже очень нравится :))

спасибо на добром слове :)

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