Ответ на »сообщение 2860« (Александр)
___________________________

Руслан по моему то о чем Вы говорите это уже документооборот, а это уже проблема не файловой системы (я имею ввиду хождение документов и их согласование).
Я думаю в концепции, если говорить о файловой системе (или об окружении файловой системы), надо определиться с ее базовыми понятиями блок, сегмент, файл, документ, образ, компонент, форматы и т.д., а также с функционалом - это иерархия хранения (диск-диск-лента или еще как нибудь неважно), версионность (файлов, документов и .д.), архивирование, резервное копирование, ЭЦП, уровни защиты (RAID) и т.д.

Александр, я рассматриваю предложение Сергея как вариант для обдумывания некоей базовой функциональности в отношении варианта перенацеливания Росы на класс Office OS. На мой вопрос о фундаментальности документа он ответил так, как я и предполагал: документ -- сопутствующая часть, специально заточенная под офисные требования (рядовому домашнему пользователю ЭЦП вряд ли понадобится).

Если говорить о той модели, которая пока вырисовывается, то она выглядит так, как я здесь ранее описывал:

1. Есть низкоуровневое представление (файл, поименованный набор байтов)
2. Есть базовое представление (назовем его, например, фреймом -- это неважно, главное -- он имеет БД-подобную структуру)
3. Есть документы (берем для определенности за отправную точку модель Сергея).

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

Кто хотел посмотреть прозрачную работу с онлайн-документами?
Будет оно и в существующих ОС: http://online-desktop.org/wiki/Online_Desktop
На странице вики есть ссылка на svn - можно "пощупать" то, что уже сделано.

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


Линейная физически или логически? Физически может быть и линейно (номер версии), а логически -- дерево. Вы как-то упустили мое замечание относительно review. Документ (если мы про офисную среду) проходит стадию согласования (по вполне конкретным маршрутам). Свое "фе" на нем могут оставлять разные лица. Как отслеживается при версионировании документа соответствие "фе" в новом документе? По старинке -- лобовым сравнением версий? Или все же как-то покультурнее?


Руслан по моему то о чем Вы говорите это уже документооборот, а это уже проблема не файловой системы (я имею ввиду хождение документов и их согласование).
Я думаю в концепции, если говорить о файловой системе (или об окружении файловой системы), надо определиться с ее базовыми понятиями блок, сегмент, файл, документ, образ, компонент, форматы и т.д., а также с функционалом - это иерархия хранения (диск-диск-лента или еще как нибудь неважно), версионность (файлов, документов и .д.), архивирование, резервное копирование, ЭЦП, уровни защиты (RAID) и т.д.

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

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

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

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

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

Вопросы:

1. Содержит ли формат достаточно информации для его разбора или же его представление регулируется внешней информацией? Другими словами, является ли он самопоясняющим (можно разобрать, "потеряв" спецификацию), либо тегирование его минимально?

2. Что означают типы приложений? Кто их формирует? Как контролируется соответствие (самим приложением или ОС)? Как обеспечивается регистрация приложения в отношении соответствующего типа ("лицензия" приложению выдается? Кем и как?)

3. Изучали ли Вы форматы ODF и Office Open XML? Насколько они соответствуют Вашим ожиданиям от документа в новой ОС?

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

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

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

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

Ответ на »сообщение 2850« (Valery Solovey)
___________________________
Однако, как видно из списка, большинство вещей предназначены для проектирования или планирования. Я же имел в виду задачи моделирования.
Подобный спор требует очень точного определения терминов.
Что именно Вы понимаете под моделированием?
Моделирование ЧЕГО и ДЛЯ ЧЕГО?
В конце концов любой план и проект тоже модель своего рода.

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


2. Может ли быть документом элемент документа (поддерживается ли иерархия включения и иерархия ли это)?

Нет. Все документы - одного уровня. Однако в документ можно внедрить мандат к другому документу, например, находящемуся на общедоступном сервере.

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

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

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

Линейная физически или логически? Физически может быть и линейно (номер версии), а логически -- дерево. Вы как-то упустили мое замечание относительно review. Документ (если мы про офисную среду) проходит стадию согласования (по вполне конкретным маршрутам). Свое "фе" на нем могут оставлять разные лица. Как отслеживается при версионировании документа соответствие "фе" в новом документе? По старинке -- лобовым сравнением версий? Или все же как-то покультурнее?

5. Какие виды информации (в Вашей схеме) не являются документами, но при этом требуют наличия самостоятельности в плане хранения, доступа, операций и т.п. Либо же всё есть документ?

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

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

Ответ на »сообщение 2845« (Борис Рюмшин)
___________________________

Если система будет открытая, то её механизмы шифрования также будут известны. Однако, "Документ зашифрован таким образом, что его структура недоступна" - это недостижимый идеал. Если ключ хранится в системе, то он станет известен при взломе. Если вне системы, то его можно добыть.
Можно. Например, если ключ генерируется на основе отпечатка пальца, то можно и палец отрезать. Но вот причем здесь защита на уровне операционной системы - я не понимаю.

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

Не согласен. Если имеется в виду XML с его длинными по отношению к полезным данным тегами, то это не тот случай. Документ универсального формата - это лишь контейнер, легкая оболочка для взаимодействия с ОС, в которую можно вложить что угодно. Средства обеспечения универсальности по отношению к вложимому - это вовсе не подробное описание формата документа. Для обеспечения универсальности не нужно так много тегов. В простейшем случае достаточно перечислить типы приложений, которые могут работать с документом.


Согласен.


Разве я возражал против хранения каких-то из резервных копий в сети? Что касается избавления от администраторов, то всё зависит от весовой категории сотрудника. Я уверен, что перед финансовым директором любой администратор будет бегать на задних лапках и обеспечит финдиректора и персональными резервными серверами, и чем угодно еще.


Что касается администраторов то, все зависит от организации труда в конторе, а не от весовой категории сотрудника (сам работал админом в разных конторах).


Разумно. Только лента - для других целей (относительно постоянные данные, архивы документов, дистрибутивы программ и той же ОС). Системные файлы много места не занимают. Можно регулярно делать много копий на разных жестких дисках - с контрольными суммами.


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


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


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