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

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

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

Недостаточно знать, что задекларировано, надо себе представлять качество и полноту реализации, а заодно -- цену вопроса: примерные трудозатраты и понимание того, что с этим хозяйством будет через 5-10 лет.


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


Думаю, не раскрою большой тайны, если скажу, что Microsoft по-разному использует свое господствующее положение для подавления любой попытки конкурировать. Давит не только превентивными маркетинговыми ударами, масштабами разработок, но и номенклатурой, требующей сопряжения и поддержки совместимости.
И зачем, скажите на милость, нам с ними "воевать"? :)

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

Не надо бояться этой войны, а надо действовать хитростью, с использованием "воинского искусства". Есть ведь и союзники в лице Linux.

Вот пример такой карты: http://www.free-soft.org/softwarewar.gif , но она, к сожалению, демонстрирует только лобовые столкновения, без обходных маневров и использования действий и ресурсов противника в свою пользу - я имею в виду именно интеграцию (тоже не "лобовую").

Ответ на »сообщение 2459« (Сергей Перовский)
___________________________
Автор - пользователь, создавший документ и единственный, имеющий право его моифицировать.
Ибо "совместная работа над документом" - опасная утопия.
Автор документа (текста, рисунка, программы) - как капитан на корабле,
может всех выслушать, но решения принимает сам и отвечает за результат сам.


Я бы не был так категоричен. Совместная работа возможна (wiki - режим), но за автором должно быть последнее слово.

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

Когда то в ОС не было GUI (да даже текстового редактора встроенного не было) :)
А сейчас попробуйте предложить ОС широкого назначения без GUI - засмеют.
Вот и пришла пора встроить в ОС СЭД и СУБД вместо файловой системы.
Что значит "встроить"? Рассмотрим на примере GUI. Одно дело "встроенность" оконных менеджеров (или даже DE) в современных дистрибутивах Linux (есть полная свобода выбора - GNOME, KDE, IceWM, Xfce, и множество других - вы можете удалить тот, который вам предустановлен и бесшовно встроить любой другой, а поверх него навесить еще и compiz или beryl). И совсем другое дело - встроенный GUI Windows.

Причем в соответствии с лозунгом разработчиков не просто какие-нибудь СЭД и СУБД, а научно проработанные и строго реализованные.
Вы уверены, что бизнес захочет именно научной проработанности, а не чего-то иного?

Ответ на »сообщение 2446« (Ка джа)
___________________________
Это одна и та же проблема.
Зачем бы понадобились СЭД, если бы задачи СЭД решались на уровне ФС(ОС)?
Когда то в ОС не было GUI (да даже текстового редактора встроенного не было) :)
А сейчас попробуйте предложить ОС широкого назначения без GUI - засмеют.
Вот и пришла пора встроить в ОС СЭД и СУБД вместо файловой системы.
Причем в соответствии с лозунгом разработчиков не просто какие-нибудь СЭД и СУБД,
а научно проработанные и строго реализованные.
 
Что значит "новый документ"? Новую копию? Не жирно? А историю изменений значит теряем?
Или создаем специальный механизм (отдельный документ "История Письма")?
Вообще что значит Автор? :-)
Будет ли физически новая копия - вопрос реализации.
Хранится ли история изменений и с какой подробностью - вопрос настройки системы.
Автор - пользователь, создавший документ и единственный, имеющий право его моифицировать.
Ибо "совместная работа над документом" - опасная утопия.
Автор документа (текста, рисунка, программы) - как капитан на корабле,
может всех выслушать, но решения принимает сам и отвечает за результат сам.

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

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

Да, об этом как-то хорошо написал Джоэл Спольски в своей статье "Огонь и движение"

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

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

Боюсь, из этого выводы об уязвимости сделать будет сложно.

Вспоминаются крылатые слова Л.Н.Толстого, написанные во время Крымской войны, при обороне Севастополя. В его песне, где "прославлялись" штабные теоретики, сумевшие привести русские войска к разгрому в сражении при Черной речке, было так: "Чисто писано в бумаге, да забыли про овраги, как по ним ходить".

Недостаточно знать, что задекларировано, надо себе представлять качество и полноту реализации, а заодно -- цену вопроса: примерные трудозатраты и понимание того, что с этим хозяйством будет через 5-10 лет.

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

Чем-то напоминает комбинированные ложные цели для защиты от ракет с радиолокационными, тепловыми и лазерными головками самонаведения (как напр., в экспериментальном истребителе С-37 "Беркут"). Ложная цель там представляет собой зону горения, образуемую в стороне от защищаемого самолета за счет использования направленной струи газов. В струю вводится воспламеняющая жидкость (в частности, ею может быть топливо, используемое двигателями летательного аппарата), распыляемая для получения топливо-газовой смеси, которая затем поджигается. Горение поддерживается в течение заданного отрезка времени. В результате спектральный состав горящего облака идентичен спектральному составу излучения защищаемого объекта ("тепло"). Плазмообразующие добавки приводят к увеличению отражения радиоволн от зоны горения и образуют свободные электроны. При их достаточно высокой концентрации горящее облако отражает радиоволны как металлическое тело ("радиолокация"). Мелкодисперсные пороши веществ рабочих тел лазеров в процессе горения либо излучают электромагнитные волны на той же частоте, на которой работает лазер подсветки цели, либо, не сгорая, выносятся за пределы области горения и в процессе охлаждения излучают электромагнитные волны требуемого диапазона. Мощность излучения должна соответствовать мощности сигнала, отражаемого от защищаемого объекта при подсветке лазером противника ("лазер").

У Microsoft примерно так же. И зачем, скажите на милость, нам с ними "воевать"? :)

Ответ на »сообщение 2434« (Илья Ермаков)
___________________________

Ответ на »сообщение 2433« (panda)
___________________________

Ответ на »сообщение 2431« (Сергей Прохоренко)
___________________________
Интегрируемость с миром Windows больше, чем WINE (WINE@Etersoft, Cedega и т.д.) будет стоить ОЧЕНЬ дорого.

Отсюда вывод... Единственный и бескровный путь интеграции с Windows - это поддержка POSIX. На базе которого при необходимости можно использовать Wine.

Вообще, было бы полезно иметь полную схему возможной интеграции "Росы" с "миром Windows" (включая Win32, .NET, драйверы, языки, трансляторы, системы программирования, библиотеки, документы пользователей) с "миром UNIX", с миром Явы, с СУБД, вебом и с прочим мейнстримом.

Ваш вывод показывает лишь один из элементов такой схемы:
"Роса" - POSIX - WINE - Приложения для Windows
Видя такую длинную цепочку, начинаешь сомневаться в её надежности, и хочется подстраховаться другими способами интеграции.

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

Ответ на »сообщение 2453« (Руслан Богатырев)
___________________________
Хотелось бы видеть более четкий и логичный критерий для проведения границы между ОС и СЭД. Для некорпоративного пользователя тоже важны некоторые удобства, предоставляемые файловой системой (поиск, упорядочивание, быстрый доступ, простота просмотра, ассоциированные приложения, связанные документы, версионность, бэкапы, синхронизация, безопасные переименования, защищенность системных файлов, приватность), которые могут быть произвольно отнесены к "корпоративным" (а разве корпоративные пользователи не важны, и их всех надо отсылать к СЭД?) и излишним. Эти удобства должны быть по крайней мере не хуже, чем у конкурирующих ОС. В конце концов, встречают по одежке, а для ОС одна из одежек - пользовательский интерфейс файловой системы.

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

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

Забыл добавить: каждая "обобщенная ссылка" идет с тегом, который и определяет ее принадлежность тому или иному классу ссылок (трактовку связей).

Некоторые мысли в отношении дискуссии по файловой системе, документам и электронному документообороту.

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

И все бы ничего, но чем дальше, тем яснее становятся проблемы такого низкоуровневого представления.

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

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

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

Мне представляется, что тут надо идти более осторожно. Да, к файлу надо добавлять более высокоуровневое понятие. Да, необходимо добавлять работу с абстракциями БД ("бортовая" БД). Да, надо задумываться о поддержке активных документов (с произвольной композицией исполняемых сущностей), о поддержке корпоративных документов (с их требованиями к документообороту). Но заменять файл на корпоративный документ? По-моему, это чересчур.

Что предлагаю: оставим пока в стороне "бортовую" СУБД. Рассмотрим схему "файл -- фрейм -- документ -- корпоративный документ". Что такое "файл" и так понятно. Вкратце упомянем остальные.

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

Документ ближе к понятию "активный документ" в системе Oberon (т.е. фрейм с поведенческими сущностями).

Корпоративный документ -– документ, облеченный в рамки требований корпоративного использования.


Некоторые пояснения в отношении понятия фрейма. Как известно, в языке Оберон одной из центральных идей, введенных Виртом, является расширение типа (type extension). Расширение типа строится на основе расширения записей:

TYPE T0 = RECORD id: INTEGER END;
TYPE T1 = RECORD (T0)  body: INTEGER END;

Т.е. T1 содержит поля id (от T0) и body. В реализации расширения типа факт связи типов отражается специальным скрытым признаком (тегом). При этом операции, применимые к T0 в отношении его полей, применимы и к T1. Расширение типа задает отношение "тип-подтип" (subtyping), но может использоваться и в ООП в качестве механизма subclassing.

Фактически Вирт предложил универсальный каркас для построения как традиционного ООП, так и для воплощения других подходов.

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

Собственно истоки этой идеи (запись как основа ООП) восходят еще к работам Тони Хоара. Некоторую ознакомительную информацию по этому вопросу я уже приводил. См. ветку "Оберон-технологии": http://www.delphikingdom.ru/asp/talktopic.asp?ID=368&ref=msg&msg=5115#msg5115

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

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

Что важно: подобная концепция может быть закреплена на уровне языка программирования Norebo (с некоторыми нюансами по отношению к type extension Вирта).