amarao (amarao_san) wrote,
amarao
amarao_san

Categories:

tagfs - примерная спецификация

благодарю анонима с пятью двойками в IP.

Итак, концепция (только концепция - реализовать её у меня пороху не хватит) tagfs - файловой системы для управления информацией с помощью тегов.

Основа (хранилище) - обычная ™ файловая система, в которой предусмотрена метаинформация [в этом месте я плаваю]. Файлы хранятся либо в виде дерева каталогов (а-ля сквидовый кеш/b-tree), либо просто тупой помойкой в каталое tagfs_files. Доступ к ним, конечно, пользователь может получить (и внести изменения), но весь цимус - в работе с файлами не с помощью "файловой системы-носителя", а с помощью tagfs. Каталогов (в пользовательском смысле) в файловой системе нет, это частный случай атрибутов файла.

В принципе, возможно "наложение" tagfs на любую файловую систему - после индексирования файлы "выдёргиваются" из их исходного места. Во время индексирования каталоги вносятся как мета-информация в данные файла.

Атрибуты файла представляют:
* его "неотъемлимые" (системные) данные: размер, дату изменения/модификации
* теги

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

Часть тегов может быть автоматически генерируемой на основании другой информации файла (например, md5, или части имени).

tagfs представляет систему видов (представлений, view) информации. Каждое представление - выборка по тегам с указанными условиями.

Частным случаем tagfs является дерево каталогов, построенное как последовательная выборка по тегу directory_name. Но, разумеется, и остальные виды так же могут быть.

Основным проблемным моментом является переосмысление файловых операций:

1) open/read/write/stat вполне однозначно определены - они выполнят указанное действие. Тут проблем нет.

А дальше начинаются проблемы:
2) создание нового файла (копирование с внешних фс на указанную) создаёт файл в хранилище и присваивает ему указанные теги. При этом, очевидно, что мы можем только присваивать теги, но никак не результат выполнения запроса. Например, если у нас представление вида 'if 'aaa' in filename, то мы не сможем создать такие теги, которые бы устраивали условие. Отсюда мысль: представления могут быть с возможностью пополнения (теговое представление) и в без него (представление запроса). Я не говорю режимы r/o и r/w, потому что возможность удаления остаётся даже для представления, которое нельзя расширить.
3) Создание каталогов == создание новой метки. Возможно это только при теговом представлении.
4) Удаление файла... Тут мы приходим к двузначности:
а) удаление файла означает удаление его из хранилища (т.е. автоматическое удаление из всех представлений)
б) удаление файла означает удаление у него того тега, который стал основой для вида.

Возникает соблазн сказать, что "удалять файл" мы будем только из представления запроса, а "удалять метку" из тегового представления. Но это внесёт жуткую путаницу, так что следует однозначно определить тип операции, эквивалентный удалению. Это будет 'generic' операция, файловый менеджер, который будет "знать" про tagfs будет иметь право вызвать альтернативный вызов.

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

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

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

Мне видится один из двух выходов:

1) Файл, добавляемый в представление запроса, помещается в группу "без тегов" и показывается в представлении "силком" (tagfs помнит, что теперь запрос выглядит так: старый_запрос + этот_файл).

2) У файла сохраняется пометка (в виде специфичного тега), что он соответствует запросу "старый_запрос" вне зависимости от чего-либо. Грубо говоря, тег выглядит так: текст_запроса=true. И при выполнении запроса это поле ищется и включается.

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

... Есть ещё третий путь, но он не совместим с generic dir i/o: возможность сделать команду 'convert selection to tag tag_name'. В результате представление запроса превращается в представление тэга и все последующие операции очевидным образом выполняются в рамках общей логики. Важным моментом будет следующее: не смотря на то, что тип представления поменялся, все открытые хэндлеры для каталога у всех приложений остались валидными. (грубо говоря, это эквивалентно переименованию каталога в обычной fs).

Итог:

tagfs-совместимый файл-менеджер должен уметь две дополнительные операции:
* Удаление файла из хранилища вообще (итого у нас есть три уровня удаления информации: delete (удаление метки), drop (удаление файла из хранилища), wipe (затирание нулями и удаление файла из хранилища).
* Конвертацию представления запроса в представление метки (теговое представление).

В принципе, вторая операция может быть и не интегрированной в файловый менеджер, а делаться отдельной командой.

Открытым остаётся вопрос о том, в каком формате хранить информацию о тегах... Метаинформация файлов - очень неудобна с точки зрения быстрой выборки. SQL - медленно (представьте себе обхождение всех сгенерированных представлений du, например), плюс нет согласованности с фс...
Tags: idea!, tagfs
Subscribe

  • концепция для вебдваноля

    Берётся онлайновое видео. Берётся вики. Итог: community driven subs. Требуется: инструментарий для версий сабов/реплик, раздельное редактирование…

  • идея для программы

    Загружать видео-файл/видео-файлы, и показывать его как набор скриншотов (стараться убрать повторы/тёмные экраны) с возможностью листать. Во-первых…

  • идея для браузера

    Плагин, который записывает перемещения по www (с учётом табов и переключения). Данные используются для 3D (2D?) рендеринга на большой лист с…

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 44 comments

  • концепция для вебдваноля

    Берётся онлайновое видео. Берётся вики. Итог: community driven subs. Требуется: инструментарий для версий сабов/реплик, раздельное редактирование…

  • идея для программы

    Загружать видео-файл/видео-файлы, и показывать его как набор скриншотов (стараться убрать повторы/тёмные экраны) с возможностью листать. Во-первых…

  • идея для браузера

    Плагин, который записывает перемещения по www (с учётом табов и переключения). Данные используются для 3D (2D?) рендеринга на большой лист с…