о файловой системе

[avva]

Ну хорошо. Может она, иерархическая файловая система то есть, действительно не нужна?

Все эти каталоги в каталогах. Широченное дерево, ползучее. Кто сказал, что именно так должно быть?

Вот в последнее время так популярно стало вместо иерархии делать метки. Вместо иерархического дерева закладок - del.icio.us, с тагами на каждом URLе. Вместо иерархического дерева фотоальбомов - Flickr с тагами на каждой картинке. И так далее.

Давайте скажем: нет никакой иерархической файловой системы. Есть файлы. У каждого файла есть набор меток. В некоторых случаях эти метки хранятся вместе с самим файлом, в некоторых - отражают то, где он хранится ("cd").

Если у файла есть метка "program", его можно запустить. Конфигурационные файлы помечены "config", а конфигурационные файлы системы имеют метки "config" и "system" одновременно. Плюс метку определённого пакета или модуля, в случае надобности.

Директорий нет. Вместо понятия текущей директории есть понятие текущего набора меток, который включает в себя те метки, что я хочу видеть, и, возможно, какие-то, которых не хочу (так файлы "system" будут скрыты от обычного пользователя). Вместо команд "dir" и "ls" есть команда, которая показывает все файлы, отвечающие текущему набору меток. Если у компьютера есть несколько пользователей, файлы каждого помечены меткой его username. Вместо команды "cd" есть команда, меняющая текущий набор меток. Графические программы для работы с файлами делают понятие текущего набора меток наглядным и легко изменяемым.

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

"Копировать файл" означает клонировать его и изменить какую-нибудь существенную метку (или добавить). Например: я программист и у меня есть проект foo, в котором 100 файлов. Я хочу сделать новую копию всего проекта и работать над ней. Создаю новую существенную метку current и клонирую весь проект в неё. Аналогом переноса файла из одного каталога в другой теперь является изменение набора существенных меток (без клонирования). Записать набор файлов на USB-диск означает выделить нужный набор файлов и склонировать их с меткой usb.

Не будет работать? Слишком сложно? Слишком неинтуитивно?

Comments

[dzz.livejournal.com]

> У каждого файла есть набор меток

В системах управления контентом (aka ECM) это называется атрибутами :)

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

С моей точки зрения, жизнеспособным является вариант, позволяющий атрибутировать файлы как плоско, так и иерархически. При этом у каждого физического файла может быть несколько вариантов координат в пространстве атрибутов. Но это в полуготовой форме тоже уже существует (см. hard links в юниксовых файловых системах). Контроль уникальности координат - задача отдельная, но тоже решаемая.

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

[dzz.livejournal.com]

Собственно, рекомендую погуглить по кодовому слову ECM

[ex-ex-zhuzh.livejournal.com]

У фильма есть атрубуты: режиссер(ы), продюсер(ы), актер(ы), год выпуска, страна (страны) выпуска и прочее. Что под чем должно лежать и почему?

[dzz.livejournal.com]

У документа есть атрибуты: проект, подпроект, версия. По отдельности они смысла не имеют.

[ex-ex-zhuzh.livejournal.com]

Может быть. Но режиссеры и актеры имеют смысл сами по себе. Сегодня мне хочется смотреть всего Феллини, а завтра всего Мастрояни. А послезавтра Вицина, Моргунова и Никулина, причем вместе, а не по отдельности.

[dzz.livejournal.com]

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

Что касается кино... Представьте себе, что я хочу найти фильм, в котором Никулин снимался в роли Балбеса. Атрибутирование деревом "актёр-роли актёра" в данном случае предпочтительнее пары атрибутов "список актёров" и "список ролей", т.к. позволяет взаимоувязывать первое со вторым.

[ex-ex-zhuzh.livejournal.com]

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

А иерархию можно завести как частный случай системы атрибутов, если нужно.

[zgee.livejournal.com]

Для метаданных в рамках Semantic Web господа из w3c сделали язык RDF, где данные организованы в граф.