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

Все большее число людей использует компьютеры. Они одновременно производят и используют все возрастающее количество файлов. Сети также послужили причиной того, что эти файлы разбросаны по нескольким компьютерам, от файловых серверов компаний до Palm Pilot'ов и iPod'ов. Пользователей мало интересует эффективность алгоритмов, накладные расходы, создаваемые базами данных, и другие технические аспекты. Они заинтересованы в том, чтобы их время не тратилось на поиски файлов. Проблема упорядочивания и нахождения файлов будет становиться только больше, никак не меньше!

Эти пользователи не работают в технических областях и не знают концепции путей и имен файлов. Каждый раз, когда им приходится использовать файловый менеджер или диалоговое окно открытия файла, им необходимо переключиться на другую область. Хуже того, большинство из них не имеет ни желания, ни способности нормально упорядочить файлы. Как часто вы видели компьютер новичка с рабочим столом, увешанным иконками файлов? Зачастую они даже не знают или не понимают каталогов. Мой отец был в панике, когда файл вышел из списка недавно использованных в Word. Он просто никогда не использовал файловый менеджер.

Полные пути файлов - просто уникальные ключи файлов, необходимые для того, чтобы обращаться к файлам без каких-либо неоднозначносте. Они играют ту же роль, что и первичные ключи в системах управления базами данных. Есть и другие системные атрибуты (несколько дат, списки контроля доступа (ACL - Access Control List), но никаких других атрибутов из конкретной области. Базы данных могут хранить и управляться со множеством других атрибутов, так что добавлять множество атрибутов, касающихся заданной области, просто. Помимо стандартного автора, заголовка и подобного, в офисе доктора могут добавить атрибуты, относящиеся к здоровью, в офисе адвоката - добавить атрибуты, относящиеся к законам, и так далее.

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

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

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

Смотрите также: В качестве примера файлового менеджера, основанного на этих и других идеях посмотрите на Dekk.

индекс статьи
страница 1 : страница без заголовка
страница 2 - текущая : страница без заголовка