>> плеером сделали, а более точно - как в винде COM-компоненты), части
> лучше как D-bus, более слабосвязанные сервисы. Только какого-то реестра с метаданными сервисов
> в духе SOA (но в разы легче по реализации) и не
> хватает.
> А COM -- это no way, слишком сильно связанные сервисы. Тот же
> Automator, кнопка "записать скрипт" -- легко реализуется в MacOSX из-за дизайна
> системы, но в общем случае не работает (при любом разрешении экрана,
> настройках, и т.п.) в Windows.Ну да. Из COM я имел в виду идею интерфейсов и компонентов, их реализующих.
>> Да что говорить - сейчас так называемые DE не поддердивают даже полноценные
>> сессии.
> ??? единственное существенное отличие DE от просто WM -- это и есть
> поддержка сессий в приложениях DE, интероперабельность между приложениями DE (чуть сложнее
> чем "открыть файл в приложении"), и общие настройки приложений/семантическая база
Пока что основное отличие DE - это попытки сделать сови велосипеды для конфигуарции всего и вся - сети, списков пользователей и т.д. А интероперабельность вроде и есть, а практичсекой пользы немного. И с семантикой та же ситуация, и улучшится она не раньше, чем то самое теговое хранилище документов появится.
>> Полноценные - это когда ты софт сохраняет в сессии все
>> свои настройки - плеер начинвает играть с того же места, где
>> остановился, в браузере открываются те же страницы, в VFS монтируются те
>> же удалённые файловые системы и архивы, читалка PDF открывается точно в
>> том месте, где и раньше, раскладка клавиатуры у всего сохранена и
> ЧДЯНТ? evince открывает с того же самого места, и т. д., и
> т.п. в каждом отдельном приложении. Правда, если приложение упадёт, не факт,
> что сессия не испортится.
> То есть, сессия должна обновляться не при закрытии приложения нормальным способом, а
> как нормальная шина данных,
Ок, против evince cтавим галочку. Кстати, насчёт падений я не уверен - как бы чрезмерную нагрузку не создать на систему.
>> в указанных виртуальных экранах, настройки прокси и т.д. Плюс умение положить
>> рядом несколько сессий и умение софта из них не мешать друг
>> другу.
> это что такое? почему софт должен сразу мешать?
Потому что если не предусмотреть, что сессий множество и не учесть, что софт не должен хранить свои временные данные вне сессий - может оказаться, что, скажем, две копии файрфокса ломают общее хранилище паролей. Понятно, что это вопрос аккуратности, но помнитьоб этом нужно - также как надо помнить о локах при многопоточном программировании.
>> Вот тогда от DE был бы смысл. А пока - это просто
>> набор одинаково выглядящего неуправляемого софта, у которого кнопки OK одинаково расположены.
> разовью мысль: полноценный DE -- это то, что позволяет работать не на
> уровне файлов, кнопок приложения или его API, а на уровне более
> общего workflow, с учётом его семантики. А как там данные передаются
> из приложения в приложение, через файлы или ещё какую там шину
> -- это неинтересные подробности реализации. Существенна именно суть этих данных в
> разрезе конкретного workflow
> Что-то вроде такого: http://etoileos.com/etoile/faq/#q3 http://etoileos.com/etoile/faq/#q7
Ну, можно и так. Я бы добавил возможность лёгкого экспорта и редактирования этих workflow и их изоляцию - то есть при добавлении нового workflow чтобы не надо было редактировать существующие. Тогда можно организовыват репозиторий workflow, что повысит и удобство, и шансы таокй системы на выживание :-)
