Если уж на то пошло, то лучше вообще отказаться от понятия файла в пользу понятия носителя данных (диска) как реляционной БД. Файла Годовой_Отчет.doc больше нет. Есть набор записей с векторной и растровой графикой, текстом и макросами обработки. При необходимости все это скопировать на другой физический диск, происходит обновление записей из одной БД в другую, с сохранением версий и мертвых ссылок.

Заодно отпадает такое понятие как "несовместимый формат файла", а также упрощается поиск информации, конвертирование данных из файла в файл больше не будет головной болью компонент связания и встраивания объектов. Для Вашей любимой программы на Delphi с отчетами не придется ставить Excel для манипулирования с файлами *.xls

Ответ на »сообщение 2391« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2389« (Сергей Перовский)
___________________________

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

В связи с репликой относительной неважности места сохранения информации вспоминается такая поучительная история, описанная Линусом Торвальдсом в его книге "Just for Fun. Рассказ нечаянного революционера". Не буду пересказывать, а просто приведу выдержку.

В начале октября была выпущена версия 0.02 с исправлением ошибок и добавлением некоторых программ. В ноябре я выпустил версию 0.03. К концу 1991-го я был уже готов остановиться. Я сделал много интересных вещей. Не все работало идеально, но в программистском мире люди часто теряют интерес к проекту, когда решены основные задачи. Со мной примерно так и было. Кому интересно вылавливать блох? Удержали меня две вещи: во-первых, я нечаянно запортил раздел с Minix, а во-вторых, мне продолжали приходить отклики. В те времена я загружался в Linux, но использовал Minix как основную среду разработки. Под Linux я в основном получал с университетского компьютера почту и новости с помощью своей программы эмуляции терминала. Поскольку университетская машина была постоянно занята, я написал программу автодозвона. Но в декабре я по ошибке позвонил вместо модема на винчестер. Вместо параметра auto-dial /dev/ttyl (последовательный интерфейс) я указал /dev/hdal (винчестер). В итоге я нечаянно попортил некоторые важные части раздела, где у меня сидела Minix. Теперь я не мог ее загружать. Это был решающий момент: можно было переустановить Minix или принять вызов и объявить, что Linux может полностью ее заменить.

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

Хотя, согласен с тем, что режим такой "безадресной" работы надо предусматривать. Равно как и режим с конкретикой и защитой от подобных ляпов.

---

Такого рода ошибки пользователей – очень частое явление. Они бы не случались, если бы файловая система не являлась слегка упорядоченной свалкой (своего рода древовидным рабочим столом) без какой-либо регламентации. В качестве образца хорошей организации данных можно взять хранилище данных (data warehouse), принципы организации которого целесообразно творчески заимствовать при построении файловой системы новой ОС:

Принцип 1. Единственность истины. => Каждый документ в хранилище документов должен быть в единственном экземпляре, а документы в разных хранилищах документов должны автоматически реплицироваться. Не должно быть одинаковых документов с разными названиями. Не должно быть документов с одинаковыми названиями – даже в разных тематических папках одного хранилища документов. Не должно быть одновременно файлов с названиями типа Vasya_1.xls и Vasya_new.xls – в котором из них более свежие данные? Не в том, который позднее сохранили без каких-либо изменений! В случае разветвления документа на такие, например, как 2008_Year_Report_for_Pasha.doc и 2008_Year_Report_for_Masha.doc, нужно иметь возможность найти порождающий их документ. Переименование ничего не должно менять в состоянии и связях документа.

Принцип 2. Единый справочник метаданных с описанием измерений («аргументов»), атрибутов/показателей («функций») и единиц измерения данных. Часть метаданных (например, описательные) может храниться вместе с объектом, а часть (включая идентификатор) хранится в каталоге метаданных. => Для документов всё аналогично.

Принцип 3. Тематическая классификация данных (в оригинале – ориентированность на предметные области или предмето-ориентированность). => Чем помещать одинаковые экземпляры файла в разные тематические папки, лучше пометить в древовидном тематическом каталоге те несколько тем, к которым относится единственный экземпляр файла. Ярлыки проблему не решают – точнее, должны быть только ярлыки, а единственный экземпляр файла не должен храниться в какой-то определенной папке. Причем, действия над любым ярлыком должны приводить к действиям над единственным экземпляром файла. Такие небезопасные операции пользователя над документами, как копирование, вырезание, перемещение и вставка, должны остаться в прошлом (там же, где оператор GOTO).

Принцип 4. Интегрированность данных (общий формат, согласованность, единое представление/единица измерения независимо от источника данных, очистка от ошибок, регулярное обновление, синхронизация, сверка и устранение противоречий, устранение избыточности, совпадения имен и общего имени для разных данных). => Привилегированное положение унифицированных форматов файлов. Контроль отсутствия висячих ссылок между документами. Принудительное обновление данных, передаваемых по ссылкам.

Принцип 5. Привязанность данных ко времени и хронологическая упорядоченность исторических данных (все данные помечены атрибутом времени). => Для документов всё аналогично.

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

Принцип 7. Распределенное в пространстве хранение и репликация данных. => Должна быть возможность поместить хранилище документов и его резервную копию на разные носители.

Принцип 8. Единые средства выгрузки, агрегации, согласования и отображения данных. => Это всё должно не отдаваться на откуп приложениям, а включаться в состав ОС.

Принцип 9. Наличие развитых средства защиты (в т.ч. авторизации и идентификации пользователей) и ограничения прав доступа не только на уровне отдельных таблиц и полей (столбцов) колонок, но и отдельных строк в таблице (класс "B1 Orange Book"). => Для документов всё аналогично.

---

Добавлю также полезные вещи, отсутствующие в хранилищах данных:
1. Возможность рецензировать/аннотировать документы, устанавливать рейтинги.
2. Сопровождение документов метаданными об источнике и приложении, генерировавшем эти данные.
3. Делегирование прав доступа к документам.

Ответ на »сообщение 2408« (anonymous.ru)
___________________________

Ответ на »сообщение 2407« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2406« (Ка джа)
___________________________

а драйверы под железо виндовые подойдут? :-)

А кто их знает? :) Может, и подойдут...

Гы-гы-гы. Классная шутка!! Очень смешно.
А WinAPI реализовывать будем?
(Ну правда, очень смешно!)
Все ведь знают проект ReactOS. У проекта весьма конкретный простые цели, просто обеспечить совместимость интерфейсов ядра с Windows NT. Заметьте, люди не пытаются создать нечто новое, с пока неясными контурами. Люди хотят что бы виндовые дрова "пошли" :)
Проект развивается... в течении 10 лет.. есть ощутимые успехи...
Чего и Вам желаю.
:)
Вот представил... Вы написали новую ОС, а под нее неожиданно пошли все виндовые дрова. Гы.

Ну, если есть уникальная железка, под которую есть только виндовые дрова, то ради нее можно и Windows запустить из-под Росы. Не надо бояться компромиссов.

Ответ на »сообщение 2404« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2401« (Ка джа)
___________________________

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

Под очень большим сомнением. Но (как бит и байт) вещь вечная и нужная.

Можно взять, к примеру, файл документа. Вложить в типовой электронный конверт безопасности (зашифровать, подписать, создать список доступа с указанием полномочий).  Поместить в ячейку СУБД вместо древовидной файловой системы. Отделить китайской стеной от файлов ОС и приложений. Выкинуть расширение, но прикрепить локально хранимые теги (в т.ч. тематические) и централизованно хранимые таблицы с метаданными. Добавить возможность аннотирования - как в списках файлов, так и прямо по изображению документа. Добавить принудительную версионность и принудительные бэкапы. Реализовать принцип "единственности истины". Забыть о необходимости файл где-то размещать. Добавить ассоциативный поиск файлов. Сделать связи между файлами нечувствительными к переименованиям файлов. Разрешить нескольким приложениям одновременно работать с файлом под контролем ОС.

Файл, конечно, вечно останется файлом, но его ведь уже мама родная не узнает.

Ответ на »сообщение 2407« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2406« (Ка джа)
___________________________

а драйверы под железо виндовые подойдут? :-)

А кто их знает? :) Может, и подойдут...

Гы-гы-гы. Классная шутка!! Очень смешно.
А WinAPI реализовывать будем?
(Ну правда, очень смешно!)
Все ведь знают проект ReactOS. У проекта весьма конкретный простые цели, просто обеспечить совместимость интерфейсов ядра с Windows NT. Заметьте, люди не пытаются создать нечто новое, с пока неясными контурами. Люди хотят что бы виндовые дрова "пошли" :)
Проект развивается... в течении 10 лет.. есть ощутимые успехи...
Чего и Вам желаю.
:)
Вот представил... Вы написали новую ОС, а под нее неожиданно пошли все виндовые дрова. Гы.

Ответ на »сообщение 2406« (Ка джа)
___________________________

а драйверы под железо виндовые подойдут? :-)

А кто их знает? :) Может, и подойдут...

а драйверы под железо виндовые подойдут? :-)

Ответ на »сообщение 2402« (Руслан Богатырев)
___________________________

Так чему удивляться, что простые вещи (Лисп, Форт, Пролог, Smalltalk, Оберон и др.) попирают ногами? Удивляться не стоит. Такова жизнь.

Забыл закончить мысль в отношении того, что на чужит ошибках нам надо учиться. Мы и учимся. Поэтому будет новый, навороченный язык, но двухэтажный, с ядром, близким к Оберону (которое будет более жестким по ограничениям). И не просто язык, а основа программирования новой ОС. Это шутка, но в любой шутке есть доля истины...

Ответ на »сообщение 2401« (Ка джа)
___________________________

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

Под очень большим сомнением. Но (как бит и байт) вещь вечная и нужная.

Ответ на »сообщение 2400« (Lisp Hobbyist)
___________________________

А если такого описания нет, к чему стремиться-то?

Вот разработаем новый язык для новой ОС. Напишем к нему четкую документацию с учетом Ваших пожеланий. И будет Вам с чего брать пример :)