Лингвофорум

Уфф, мудрено...Что из себя представляет рабочая область?
Нужно специально спроектированное приложение, некая студия: процесс для отображения древа проекта, и отдельно вызываемые утилиты для работы с разными данными его частей.
См. также COM и DDE.

пс: не думаю, что есть готовые решения. Берите напильник и пилитепишите.

Цитата: Sutinator от марта 31, 2014, 11:59
Я так понимаю, хранить документ в памяти необходимо В ЦЕЛЯХ редкого обращения к диску, а т.ж. скорости i/o?

Нет. Цель — не хранить документ в памяти (вместо диска); цель — хранить рабочее представление документа в месте, изолированном от прочего кода. Под рабочим представлением документа я имею в виду некое дерево структур, с которым программа может работать в конкретный момент времени. Разумеется, документ можно сериализовать и сохранить на диск, всё-такое. Я не о том. Я, наверное, конечно, over-engineer (переинженериваю?), но хостить сам документ в том же процессе, что и логика — не 100% безопасно. Если в программе есть ошибка типа переполнения буфера, то забагованный код может повредить рабочую модель документа в памяти, и бэкапь не бэкапь — забэкапишь повреждённый документ. И прощай работа нескольких часов, а то и дней. Конечно, можно применять что-то вроде CRC для верификации структур — но не муторнее ли это? Плюс, при CRC-верификации мы только можем сказать, что данные повреждены, мы не можем предостеречься от этого так, чтобы этого не происходило вообще.

Наверно не все так как ув. Гринь, могут не то чтобы думать но и осмысленно читать на английцких языках. По-Русски:
(wiki/m) RAM_drive

Я так понимаю, хранить документ в памяти необходимо В ЦЕЛЯХ редкого обращения к диску, а т.ж. скорости i/o?

На всякий случай: MS Office восстанавливает все несохранённые результаты работы после крашей.

Если я правильно понял чего Вы хотите (проекция ФС в ОЗУ), то должно помочь такое средство, как RAM drive - (wiki/en) RAM_drive

Цитата: Triton от марта 30, 2014, 12:08
Вот стабильность и не стоит затраченных денег для большинства приложений.

Ну мой софт, подразумевается, будет оперировать большим количеством данных, в том числе, с кэшем промежуточных представлений в RAM (кэш принадлежит логике и UI, а не самому документу), поэтому out of memory вполне могут быть частыми, особенно на более слабых компьютерах. В похожей программе у меня частенько внезапно бывают out of memory, и тогда теряются последние изменения, что реально бесит.

Цитата: Алексей Гринь от марта 30, 2014, 12:03
Что касается унификации интерфейсов для оффлайна и онлайна, я вот вспомнил, что в совр. версиях Minecraft'а оффлайн-режим это на деле локалхостный сервер. Так что разумно было бы сделать такое «на вырост» (оффлайн — это изначально локалхостный сервер), чтобы потом не пришлось переписывать код (как в том же Minecraft).

Да, при проектировании на вырост это разумно. Собственно, это первое, что пришло мне на ум при чтении топика.

Цитата: Алексей Гринь от марта 30, 2014, 12:03
Может быть, всё-таки OpenOffice делает так  Если запускаю его, то он сразу три процесса создаёт.

У меня так:
> 16598 /bin/sh /usr/bin/lowriter
> 16600 /usr/lib/libreoffice/program/oosplash --writer
> 16615 /usr/lib/libreoffice/program/soffice.bin --writer --splash-pipe=5

Имхо, по названиям видно, что нужен только soffice.bin. Если его вручную запустить, запускается и работает.