OberonCore

Однако, у меня такое чувство, что идея с объединением меню может быть не нова...

Мне интересна именно проблема инсталяция/деинсталяция = распаковка/удаление (папки) и пути её решения для ББ.

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

В такой форме проблема нерешаема

Я за простоту установки/удаления не только для пользователя, но и для разработчика.

От Config избавиться можно, если ввести соглашение, что у компонента должен быть определённый модуль с обработчиком сообщений среды: типа сообщение OnBlackBoxStart и т.п.

Кажется, стоит включить такой механизм в наш 1.6 в дополнение к стандартному Config. Не особо большие изменения среды нужно, чтобы это обеспечить.

Задача (2) разрешается (при условии независимости подсистем и наличии готовых кодовых/символьных файлов) командой типа ???Cmds.DecodeThis "path" Sub1 Sub2 MySub.

ТЕХНИЧЕСКОЕ ЗАДАНИЕ
на подсистему Metasystems Package Manager
для BlackBox Component Builder
(название директории подсистемы - Mtpm)

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

1. Устройство пакета
Возможны два варианта:
а) пакет представляет собой бинарный файл собственного формата, содержащий в себе все файлы пакета и другую необходиму информацию. Для работы с пакетом в BlackBox инсталлируется специальный конвертор (Convertres.Converter), который позволяет пользователю выбрать открываемый пакет с помощью диалога открытия файла. Далее открывается диалог с информацией о пакете, контроле безопасности и вариантами дальнейших действий. Затем может быть открыт некоторый стартовый документ из пакета.
б) пакет представляет собой отображение, хранящее в себе все данные пакета, и внедряемое в некоторый документ, с которым пакет и распространяется. Пользователь открывает документ обычным образом, после чего сценарий действий аналогичен (а). Примечание: отображение при своей загрузке, очевидно, не считывает данные пакета в память, а всего лишь запоминает тот файловый курьер, через который ведется загрузка (reader(Stores.Reader).rider(Files.Reader)), как это делает, например, TextModels.Model.

Следует принять и реализовать один из данных вариантов (возможно, что даже оба).

2. Контроль происхождения и безопасности
Загрузчик пакетов должен каким-то образом определять происхождение пакета и его безопасность. Видимо, приемлемым будем механизм сертификации пакетов с помощью цифровых подписей. Вместе с пакетом распространяется информация о создателе пакета и URL, по которому может быть запрошен открытый ключ ассиметричного алгоритма шифрования RSA. Загрузчик пакета проверяет корректность цифровой подписи относительно данного открытого ключа. Пользователь может принять решение о подлинности информации о пакете и его безопасности на основании своего доверия/недоверия к тому источнику, который опубликовал данный открытый ключ.

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

3. Монтирование виртуальной файловой системы пакета
Пакет содержит в себе виртуальную файловую систему, которая монтируется в Framework через модуль Files. Полностью аналогично работе HostPackedFiles.

4. Загрузка модулей в память
Выполняется средой обычным образом, для файлов, монтированных в п.3.

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

1) между загружаемым пакетом и другим пакетом, загруженным ранее.
В таком случае пользователю должно быть сообщено о невозможности совместной работы двух пакетов и предложено на выбор три варианта дальнейших действий:
а) менеджер пакетов выгрузит предыдущий пакет и загрузит требуемый;
б) менеджер пакетов запустит второй экземпляр среды, в котором открыет требуемый пакет;
в) загрузка пакета будет отменена.

2) между загружаемым пакетов и постоянными подсистемами/файлами/модулями той среды, в которой открывается пакет.
В таком случае пользователю должна быть сообщена информация о проблеме и предложены два варианта:
а) конфликтующие модули будут выгружены. Конфликтующие объекты файловой системы будут перекрыты виртуальными.
б) загрузка пакета будет отменена.


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

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

попроще надо бы

Не нова, не нова. Подождите до понедельника - их есть у меня