Этот пост является переводом вот этой написанной сегодня статьи.
Пост приглянулся мне прежде всего тем, что автор приходит к идее общего хранилища данных, и затрагивает тренд кросс-девайсности, который раскочегарили последние изменения в Mac/iOS.
Итак, пишет Chani Armitage.
Я пытался написать этот пост в течение многих месяцев, и обычно все заканчивалось или полным ступором, или еще какими-нибудь недоразумениями. Так что, забить — я начну писать, а потом посмотрим, что получится.
О чем я хотел рассказать, так это о сессиях, об XSMP, и о Вейленде.
Активности (KDE Activities) используют XSMP, X Session Management Protocol, иксовый протокол управления сессиями. Они используют его для сохранения и восстановления групп окон. Раньше он использовался только для возобновления сессии при входе в систему. На самом деле, этот протокол гораздо лучше, чем о нем обычно думают, и он отлично служил на протяжении десятков лет — но времена меняются. Если мы хотим двигаться вперед и делать такие крутые штуки как общие сессии для нескольких устройств, нужно что-то новое. Даже в Активностях, раз уж они теперь расширяют ограничения XSMP, есть множетво спрятанных отвратительных костылей, которые не нужны.
Итак, ключевой момент в том, что если мы хотим заменить древнюю, но надежную, технологию чем-то новым, то мы хотим, чтобы это нечто новое было не просто лучше, а намного лучше. Что-то, на что действительно стоит перебраться. Маленькие проблемы вроде отсутствия в XSMP автосохранения легко решаются; но есть и большая проблема, заключающаяся в том, что XSMP основан на процессах. Ключи сессий сопоставлены отдельным процессам, и когда нужно восстанавливаться, это происходит с помощью вызоыва какого-то конкретного бинарника, которому ключ сессии передается в виде аргумента. Это и есть корень зла; для начала, когда у процесса есть множество окон (типа консоли), нельзя правильно раскидать эти окна по нескольким сессиям — поэтому Активности должны делать всякую гадость, чтобы спрятать это от пользователя. Во-вторых, еще большая проблема в том, что подобный способ до смешного непереносим и непрозрачнен. Что если бинарник программы куда-то переместился? Что если пользователь стал использовать альтернативное приложение в замен старому? И, конечно, на сотовом телефоне пользователя не установлены те же самые программы, что на стационарном компьютере! Даже если у него телефон на meego, и он использует Calligra на всех своих мобильных и не-мобильных устройствах, бинарник на телефоне будет называться по-другому. :P
И что нам делать? Давайте использовались ресурсы! :) Будем хранить данные в стандартном месте в стандартном формате. Чтобы менеджер сессий, вместо того, чтобы видеть «в этой сессии находятся /usr/bin/firefox, /usr/bin/konsole and /usr/bin/okular», видел «в этой сессии находятся веб-страницы X, Y и Z, которые в прошлый раз на этом устройстве открывались с помощью firefox, причем X и Y сгруппированы в одном окне; два терминала, для которых в прошлый раз использовалась konsole; и foo.pdf, открытый на странице 3, который в прошлый раз на этом устройстве открывался с помощью okular». Тогда если okular не доступен, он может запросить у системы программу для открытия pdf, и поэтому, когда пользователь посылает сессию на телефон, абсолютно неважно, что на телефоне используется другой pdf-ридер, или даже что телефонный браузер не поддерживает табы. Кроме того, если вместо 3 страниц открыто 20, телефон может сказать «ойойой, это как-то многовато; я открою только первые три, а ссылки на все остальные буду отображать в специальном месте». Или, например, я могу задуматься: «зачем же я создал активность под названием 'фигня какая-то'? Какого черта там находится?», и могу получить ответ даже без необходимости загружать эту сессию.
Другая сторона медали в том, что мелочи решают. Недавно слышал, что в OSX добавилась серьезная поддержка сессий; они научились на примере iPhone и применили полученные знания к десктопу. Теперь есть система, для которой абсолютно неважно, если вдруг приложение отвалится — операционная система может убить его когда захочет — поддержка сессий настолько хороша, что приложение восстановится до такого же состояния, в котором было раньше. Очень приятно было бы видеть поддержку сессий подобного качества и в линуксах тоже; в приложениях KDE поддержка XSMP уже довольно хороша, но она может быть еще лучше (а до этого, протокол автосохранения должен пройти долгий путь).
Теперь, замена XSMP не является какой-то абсолютно новой идеей. Гномерам XSMP не нравился довольно давно, хотя я не думаю, что кто-то из них предпринял шаги по созданию альтернативы (а для их целей XSMP всё равно подходит). Когда я говорил с ребятами из команды Nepomuk много месяцев назад о сессиях, переносимых между устройствами, оказалось, что они уже думали об этом — но решили, что политическая часть подобного проекта будет слишком сложна. Они все еще могут быть оказаться правы — посмотрим. Но попробовать стоит. :)
Так в чем сложность, спросите вы? Вот проблема, на которой я застрял в разработке XSMP для Активностей: наличие нового протокола означает, что нужно убедить приложения поддерживать этот протокол. Поддержка XSMP, хотя и не без проблем, в последнее время стала широко распространенной и вызывала совсем немного сопротивления. Новый протокол… ну, я почти уверен, что в KDE им воспользуются, но хочется, чтобы когда-нибудь он стал частью приложений и на gtk, и на чистом qt, и на meego, и даже на кривых проприетарных поделках. И вот это уже — настоящее испытание! :)
Так что, как нам выжить в этом испытании? Для начала, мы всем объясним, какие плюшки он добавит — надеюсь, выше я описал это достаточно хорошо. Во-вторых, мы предоставим разработчикам приложений хорошо спроектированный, легко используемый API, это должно вызвать реакцию разработчиков, которые действительно что-то делают; недавно в IRC я видел человека, ругающегося на XSMP :) В-третьих, как только у нас будет достаточно сочувствующих, чтобы знать, что результат стоит попыток, мы покажем им надежную реализацию, которая будет действительно работать (без критических багов). Видеть — значит верить, верно? Никто не хочет тратить драгоценное время на создание кода для системы, которой еще не существует, поэтому как только мы сделаем минимальный набор фич, спортируем парочку приложений, мы сразу покажем всё это. Четвертое — секретное оружие :) Вейленд набирает популярность, и когда приложения начнут переходить на него, они смогут перейти и на наш протокол тоже, верно? В Вейленде нет своего собственного протокола сессий, наш протокол может им стать.
Так что, кто со мной? До Desktop Summit осталось всего несколько дней как, и, внезапно, я — его органзатор (yahhoo!), и я хотел бы там подискутировать на вышеописанные темы. В конце концов, это отличное место для чего-то, что нацелено быть переносимым между устройствами, десктопами и вообще всем чем хочешь.
TL;DR: основанный на ресурсах протокол сессий позволит нам делать действительно крутые вещи, поэтому замена XSMP стоит вложенных в нее усилий.
Теперь, я хочу углубиться в технические детали (у меня достаточно материала чтобы написать целую работу по этой теме, если бы не этот чертов синдром плохого писателя...)
…
А, о чем мы, технические детали. Что действительно нужно реализовать? Какое API нам нужно?
Есть три взаимосвязанные части. Первая — общее хранилище. Оно идет первее остальных, потому что XSMP ничего не рассказывает о том, как хранятся данные сессии; приложения могут сразу запускаться используя эти данные, или продолжать запускаться сервером XSMP (это может оказаться хорошим решением на этапе миграции. Это будет долго. Ничто настолько большое не изменяется быстро.)
Ладно… Я не очень сильно изучал хранилища. Можно хранить в nepomuk/tracker/zeitgeist, или в текстовых файлах типа kconfig, или даже в реестре (eek) — действительно важно только то, чтобы система хорошо справлялась со своими задачами, и чтобы все приложения на устройстве использовали только её. Может оказаться, что для разных устройств подходят разные бэкенды — я еще не разобрался в этом, и хотеось бы услышать какую-нибудь информацию по поводу положительных и отрицательных сторон различных подходов. Приложения будут регулярно обновлять определенные данные — нормер страницы, позицию в фильме, итд — поэтому хотелось бы услышать еще и соображения насчет эффективности.
Как минимум, я сделал грубый набросок формата данных. Основной частью ресурсов будут какие-нибудь URI (обычно локальные или http) и позиция внутри документа. URI становится ключом, а позиция — одним из полей… Другие поля будут окнами, в которых сей ресурс находится (в конце концов, окна все еще остаются логической единицей оконных менеджеров, а их позиция и размер являются важными данными сессии), в последний раз использованными приложениями, собственными полями данных для программы (желательно, чем меньше, тем лучше), и, возможно данными с других устройств (чтобы помочь с решениями, с которыми устройство не справится само, или в случае переноса сессии на какие-то устройства, где эти данные будут иметь смысл). Данные сессий для окон будут записываться, возможно, самим window manager'ом… Реально, мне нужно чистую доску и еще программистов чтобы придумать хорошие структуры данных, именно поэтому я собираюсь сделать это в Берлине. И я уверен, что даже эти решения изменятся в ходе реализации :) Для начала важно построить хоть какую-то основанную на ресурсах структуру, которая будет работать.
Вторая часть — менеджер сессий. Это программа — скорее всего, демон, но не обязательно — которая загружает приложения при открытиии сессии и говорит им закрыться, когда это необходимо. Если существуют какие-то интерактивные процессы («хотите ли вы сохранить этот документ?»), это тоже должно обрабатываться. Это то, что сейчас для XSMP делает ksm-server. На самом деле, это не займет много времени, большей частью оно уйдет на чтение и написание файлов конфигурации, но все осложняется возможностью приложений запрашивать общение с пользователем (приостанавливая закрытие сессии) или даже отменять его целиком.
Третья часть — прозрачный API, та часть, которую увидят большинство разработчиков. Я хочу, чтобы API было хорошим. Также я хотел бы иметь обратную и прямую совместимость; протокол XSMP никогда не изменялся, разве что чтобы поправить баги реализации или ошибки в дизайне, но новый протокол будет меняться. Большинство приложений будут иметь общую динамически слинкованную библиотеку, но должны ли мы беспокоиться о статически слинкованных? К счастью, мы придумали дизайн, который довольно хорошо справляется с такими случаями. Вспоминается dbus; он описывает такой формат шины, который позволяет приложениям всегда общаться на одном языке, но в этом есть и недостаток — они никогда не смогут улучшить этот формат. :/
Говоря о dbus, она из вещей которая меня интересует, как менеджер сессий и приложения должны общаться между собой? Думаю, хранилище должно быть написано так, чтобы быть доступным как можно более напрямую, по соображениям эффективности (конфликты одновременной записи будут исчезающе редкими, если вообще будут, и я ожидаю того же от конфликтов одновремменной записи и чтения). Мы можем ожидать чего-то вроде резкого понижения производительности, если буфер файловой системы будет слишком мал; в наихудшем случае, представьте, как тысячи приложений начинают обновлять свое состояние раз в 10 секунд без всякой синхронизации; может оказаться, что происходит более одной операции записи в секунду. К счастью, приложений, которые будут делать такие регулярные обновления, будет немного, одно или два (можно смотреть только одно кино, или даже когда читаешь — слушать фоновую музыку только из одного источника), но все равно это нечто, о чем стоит задуматься позднее.
Упс, я слегка отклонился; вернемся к общению с менеджером сессий. Когда я обновлял ksmserver и kwin для поддержки под-сессий (то есть, активностей), я влип в болото с разруливанием таймаутов в dbus. Скорее всего, не я один прошел этот путь, но я не знаю ни одной альтернативы. XSMP использует какой-то древний протокол под названием ICE, который, кажется, жестко завязан на X11; есть много протоколов с таким именем, так что гуглинг по нему довольно неприятен. В любом случае, я хочу разорвать завязку на X11, да так, чтобы это можно было легко сделать и с Вейлендом — что они там используют для общения?
Продолжая рассуждать дальше (руки уже устали писать, несмотря на то, что делаю регулярные перерывы), API в точности задается теми возможностями, которые предоставляет. Думаю, что из первой версии нужно выкинуть все возможности, кроме самых жизненно-необходимых; таких как общение с пользователем и отмена закрытия сессии. Я склоняюсь к полной отмене. Сейчас 2011, а не 1990; приложения должны вести себя правильно, когда наступает их время закрываться. Даже у kate сейчас есть файлы подкачки чтобы восстановиться после вылетания; они могут быть использованы и для возобновления сессии. Единственный минус в том, что они не такие уж и переносимы… но, думаю, эту проблему можно отложить ;) Черт, я должен отложить даже возможность добавить одно окно к N сессиям одновременно; это так сильно всё осложняет, что я уже не уверен, что это действительно стоящая фича для Активностей, но при этом сия возможность все равно должна быть доступна под капотом, реализованная созданием дополнительных сессий.
Итак, какие возможности нам действительно нужны?
— приложение или window manager должны записывать размер и позицию окон. Если в конце концов этим будет заниматься приложение, это должно происходить абсолютно автоматически, с помощью библиотеки, а не чего-то о чем должен беспокоиться разработик приложения
— приложениям нужно записывать тот факт, что они отображают ресурс в каком-то определенном окне
— также им нужно записывать, что они перестали отображать его :)
— или окно, или ресурс должны быть ассоциированы с определенной сессий в момент отображения
— приложениям нужно говорить, когда им стоит закрыться
— приложения должны иметь возможность восстановить себя из данных сессии
— прложения должны иметь метод хранения своих собственных нестандартных данных в сессии
Это всего лишь основа основ, копирующая возможности XSMP. Чтобы сделать нечто действительно крутое, мы должны сделать еще и это:
— говорить приложению, какие именно окна нужно закрыть, если эти окна распределены между несколькими сессиями
— говорить приложению, должно ли оно возобновить всю сессию или только ее часть
— разрешать и поощрять приложения в том, чтобы они хранили общие переносимые данные сессии (такие как позицию в документе) в стандартном месте, и так, чтобы любое приложение могло воспользоваться этими данными
Уверен, что пропустил пару вещей, но вы уже поняли идею :)
На самом деле, существует и четвертая часть: синхронизация между устройствами. Как два устройства будут обмениваться своими данными сессии? Высылание списка ресурсов и связанных данных звучит чем-то довольно простым, но есть множество деталей, в которых еще стоит разобраться — какие ресурсы нужно копировать на другие устройства, как обходиться с изменением URI (файл /home/chani/Documents/foo.pdf на станционарном компьютере окажется на телефоне где-то в совсем другом месте), когда пытаться синхронизироваться и как разрешать конфликты… :) Уверен, есть люди, понимающие во всем этом гораздо больше меня. И, в качестве бонуса, получившийся код синхронизации должен быть готов для переноса между дистрибутивами, и даже, когда-нибудь, между большинством различных бэкендов для хранения данных.
Реализация всего этого займет время, адаптация займет еще больше времени. Это — проект на много лет. Но, если люди действительно чего-то захотят, все это вполне реализуемо.
Пост приглянулся мне прежде всего тем, что автор приходит к идее общего хранилища данных, и затрагивает тренд кросс-девайсности, который раскочегарили последние изменения в Mac/iOS.
Итак, пишет Chani Armitage.
Я пытался написать этот пост в течение многих месяцев, и обычно все заканчивалось или полным ступором, или еще какими-нибудь недоразумениями. Так что, забить — я начну писать, а потом посмотрим, что получится.
О чем я хотел рассказать, так это о сессиях, об XSMP, и о Вейленде.
Активности (KDE Activities) используют XSMP, X Session Management Protocol, иксовый протокол управления сессиями. Они используют его для сохранения и восстановления групп окон. Раньше он использовался только для возобновления сессии при входе в систему. На самом деле, этот протокол гораздо лучше, чем о нем обычно думают, и он отлично служил на протяжении десятков лет — но времена меняются. Если мы хотим двигаться вперед и делать такие крутые штуки как общие сессии для нескольких устройств, нужно что-то новое. Даже в Активностях, раз уж они теперь расширяют ограничения XSMP, есть множетво спрятанных отвратительных костылей, которые не нужны.
Итак, ключевой момент в том, что если мы хотим заменить древнюю, но надежную, технологию чем-то новым, то мы хотим, чтобы это нечто новое было не просто лучше, а намного лучше. Что-то, на что действительно стоит перебраться. Маленькие проблемы вроде отсутствия в XSMP автосохранения легко решаются; но есть и большая проблема, заключающаяся в том, что XSMP основан на процессах. Ключи сессий сопоставлены отдельным процессам, и когда нужно восстанавливаться, это происходит с помощью вызоыва какого-то конкретного бинарника, которому ключ сессии передается в виде аргумента. Это и есть корень зла; для начала, когда у процесса есть множество окон (типа консоли), нельзя правильно раскидать эти окна по нескольким сессиям — поэтому Активности должны делать всякую гадость, чтобы спрятать это от пользователя. Во-вторых, еще большая проблема в том, что подобный способ до смешного непереносим и непрозрачнен. Что если бинарник программы куда-то переместился? Что если пользователь стал использовать альтернативное приложение в замен старому? И, конечно, на сотовом телефоне пользователя не установлены те же самые программы, что на стационарном компьютере! Даже если у него телефон на meego, и он использует Calligra на всех своих мобильных и не-мобильных устройствах, бинарник на телефоне будет называться по-другому. :P
И что нам делать? Давайте использовались ресурсы! :) Будем хранить данные в стандартном месте в стандартном формате. Чтобы менеджер сессий, вместо того, чтобы видеть «в этой сессии находятся /usr/bin/firefox, /usr/bin/konsole and /usr/bin/okular», видел «в этой сессии находятся веб-страницы X, Y и Z, которые в прошлый раз на этом устройстве открывались с помощью firefox, причем X и Y сгруппированы в одном окне; два терминала, для которых в прошлый раз использовалась konsole; и foo.pdf, открытый на странице 3, который в прошлый раз на этом устройстве открывался с помощью okular». Тогда если okular не доступен, он может запросить у системы программу для открытия pdf, и поэтому, когда пользователь посылает сессию на телефон, абсолютно неважно, что на телефоне используется другой pdf-ридер, или даже что телефонный браузер не поддерживает табы. Кроме того, если вместо 3 страниц открыто 20, телефон может сказать «ойойой, это как-то многовато; я открою только первые три, а ссылки на все остальные буду отображать в специальном месте». Или, например, я могу задуматься: «зачем же я создал активность под названием 'фигня какая-то'? Какого черта там находится?», и могу получить ответ даже без необходимости загружать эту сессию.
Другая сторона медали в том, что мелочи решают. Недавно слышал, что в OSX добавилась серьезная поддержка сессий; они научились на примере iPhone и применили полученные знания к десктопу. Теперь есть система, для которой абсолютно неважно, если вдруг приложение отвалится — операционная система может убить его когда захочет — поддержка сессий настолько хороша, что приложение восстановится до такого же состояния, в котором было раньше. Очень приятно было бы видеть поддержку сессий подобного качества и в линуксах тоже; в приложениях KDE поддержка XSMP уже довольно хороша, но она может быть еще лучше (а до этого, протокол автосохранения должен пройти долгий путь).
Теперь, замена XSMP не является какой-то абсолютно новой идеей. Гномерам XSMP не нравился довольно давно, хотя я не думаю, что кто-то из них предпринял шаги по созданию альтернативы (а для их целей XSMP всё равно подходит). Когда я говорил с ребятами из команды Nepomuk много месяцев назад о сессиях, переносимых между устройствами, оказалось, что они уже думали об этом — но решили, что политическая часть подобного проекта будет слишком сложна. Они все еще могут быть оказаться правы — посмотрим. Но попробовать стоит. :)
Так в чем сложность, спросите вы? Вот проблема, на которой я застрял в разработке XSMP для Активностей: наличие нового протокола означает, что нужно убедить приложения поддерживать этот протокол. Поддержка XSMP, хотя и не без проблем, в последнее время стала широко распространенной и вызывала совсем немного сопротивления. Новый протокол… ну, я почти уверен, что в KDE им воспользуются, но хочется, чтобы когда-нибудь он стал частью приложений и на gtk, и на чистом qt, и на meego, и даже на кривых проприетарных поделках. И вот это уже — настоящее испытание! :)
Так что, как нам выжить в этом испытании? Для начала, мы всем объясним, какие плюшки он добавит — надеюсь, выше я описал это достаточно хорошо. Во-вторых, мы предоставим разработчикам приложений хорошо спроектированный, легко используемый API, это должно вызвать реакцию разработчиков, которые действительно что-то делают; недавно в IRC я видел человека, ругающегося на XSMP :) В-третьих, как только у нас будет достаточно сочувствующих, чтобы знать, что результат стоит попыток, мы покажем им надежную реализацию, которая будет действительно работать (без критических багов). Видеть — значит верить, верно? Никто не хочет тратить драгоценное время на создание кода для системы, которой еще не существует, поэтому как только мы сделаем минимальный набор фич, спортируем парочку приложений, мы сразу покажем всё это. Четвертое — секретное оружие :) Вейленд набирает популярность, и когда приложения начнут переходить на него, они смогут перейти и на наш протокол тоже, верно? В Вейленде нет своего собственного протокола сессий, наш протокол может им стать.
Так что, кто со мной? До Desktop Summit осталось всего несколько дней как, и, внезапно, я — его органзатор (yahhoo!), и я хотел бы там подискутировать на вышеописанные темы. В конце концов, это отличное место для чего-то, что нацелено быть переносимым между устройствами, десктопами и вообще всем чем хочешь.
TL;DR: основанный на ресурсах протокол сессий позволит нам делать действительно крутые вещи, поэтому замена XSMP стоит вложенных в нее усилий.
Теперь, я хочу углубиться в технические детали (у меня достаточно материала чтобы написать целую работу по этой теме, если бы не этот чертов синдром плохого писателя...)
…
А, о чем мы, технические детали. Что действительно нужно реализовать? Какое API нам нужно?
Есть три взаимосвязанные части. Первая — общее хранилище. Оно идет первее остальных, потому что XSMP ничего не рассказывает о том, как хранятся данные сессии; приложения могут сразу запускаться используя эти данные, или продолжать запускаться сервером XSMP (это может оказаться хорошим решением на этапе миграции. Это будет долго. Ничто настолько большое не изменяется быстро.)
Ладно… Я не очень сильно изучал хранилища. Можно хранить в nepomuk/tracker/zeitgeist, или в текстовых файлах типа kconfig, или даже в реестре (eek) — действительно важно только то, чтобы система хорошо справлялась со своими задачами, и чтобы все приложения на устройстве использовали только её. Может оказаться, что для разных устройств подходят разные бэкенды — я еще не разобрался в этом, и хотеось бы услышать какую-нибудь информацию по поводу положительных и отрицательных сторон различных подходов. Приложения будут регулярно обновлять определенные данные — нормер страницы, позицию в фильме, итд — поэтому хотелось бы услышать еще и соображения насчет эффективности.
Как минимум, я сделал грубый набросок формата данных. Основной частью ресурсов будут какие-нибудь URI (обычно локальные или http) и позиция внутри документа. URI становится ключом, а позиция — одним из полей… Другие поля будут окнами, в которых сей ресурс находится (в конце концов, окна все еще остаются логической единицей оконных менеджеров, а их позиция и размер являются важными данными сессии), в последний раз использованными приложениями, собственными полями данных для программы (желательно, чем меньше, тем лучше), и, возможно данными с других устройств (чтобы помочь с решениями, с которыми устройство не справится само, или в случае переноса сессии на какие-то устройства, где эти данные будут иметь смысл). Данные сессий для окон будут записываться, возможно, самим window manager'ом… Реально, мне нужно чистую доску и еще программистов чтобы придумать хорошие структуры данных, именно поэтому я собираюсь сделать это в Берлине. И я уверен, что даже эти решения изменятся в ходе реализации :) Для начала важно построить хоть какую-то основанную на ресурсах структуру, которая будет работать.
Вторая часть — менеджер сессий. Это программа — скорее всего, демон, но не обязательно — которая загружает приложения при открытиии сессии и говорит им закрыться, когда это необходимо. Если существуют какие-то интерактивные процессы («хотите ли вы сохранить этот документ?»), это тоже должно обрабатываться. Это то, что сейчас для XSMP делает ksm-server. На самом деле, это не займет много времени, большей частью оно уйдет на чтение и написание файлов конфигурации, но все осложняется возможностью приложений запрашивать общение с пользователем (приостанавливая закрытие сессии) или даже отменять его целиком.
Третья часть — прозрачный API, та часть, которую увидят большинство разработчиков. Я хочу, чтобы API было хорошим. Также я хотел бы иметь обратную и прямую совместимость; протокол XSMP никогда не изменялся, разве что чтобы поправить баги реализации или ошибки в дизайне, но новый протокол будет меняться. Большинство приложений будут иметь общую динамически слинкованную библиотеку, но должны ли мы беспокоиться о статически слинкованных? К счастью, мы придумали дизайн, который довольно хорошо справляется с такими случаями. Вспоминается dbus; он описывает такой формат шины, который позволяет приложениям всегда общаться на одном языке, но в этом есть и недостаток — они никогда не смогут улучшить этот формат. :/
Говоря о dbus, она из вещей которая меня интересует, как менеджер сессий и приложения должны общаться между собой? Думаю, хранилище должно быть написано так, чтобы быть доступным как можно более напрямую, по соображениям эффективности (конфликты одновременной записи будут исчезающе редкими, если вообще будут, и я ожидаю того же от конфликтов одновремменной записи и чтения). Мы можем ожидать чего-то вроде резкого понижения производительности, если буфер файловой системы будет слишком мал; в наихудшем случае, представьте, как тысячи приложений начинают обновлять свое состояние раз в 10 секунд без всякой синхронизации; может оказаться, что происходит более одной операции записи в секунду. К счастью, приложений, которые будут делать такие регулярные обновления, будет немного, одно или два (можно смотреть только одно кино, или даже когда читаешь — слушать фоновую музыку только из одного источника), но все равно это нечто, о чем стоит задуматься позднее.
Упс, я слегка отклонился; вернемся к общению с менеджером сессий. Когда я обновлял ksmserver и kwin для поддержки под-сессий (то есть, активностей), я влип в болото с разруливанием таймаутов в dbus. Скорее всего, не я один прошел этот путь, но я не знаю ни одной альтернативы. XSMP использует какой-то древний протокол под названием ICE, который, кажется, жестко завязан на X11; есть много протоколов с таким именем, так что гуглинг по нему довольно неприятен. В любом случае, я хочу разорвать завязку на X11, да так, чтобы это можно было легко сделать и с Вейлендом — что они там используют для общения?
Продолжая рассуждать дальше (руки уже устали писать, несмотря на то, что делаю регулярные перерывы), API в точности задается теми возможностями, которые предоставляет. Думаю, что из первой версии нужно выкинуть все возможности, кроме самых жизненно-необходимых; таких как общение с пользователем и отмена закрытия сессии. Я склоняюсь к полной отмене. Сейчас 2011, а не 1990; приложения должны вести себя правильно, когда наступает их время закрываться. Даже у kate сейчас есть файлы подкачки чтобы восстановиться после вылетания; они могут быть использованы и для возобновления сессии. Единственный минус в том, что они не такие уж и переносимы… но, думаю, эту проблему можно отложить ;) Черт, я должен отложить даже возможность добавить одно окно к N сессиям одновременно; это так сильно всё осложняет, что я уже не уверен, что это действительно стоящая фича для Активностей, но при этом сия возможность все равно должна быть доступна под капотом, реализованная созданием дополнительных сессий.
Итак, какие возможности нам действительно нужны?
— приложение или window manager должны записывать размер и позицию окон. Если в конце концов этим будет заниматься приложение, это должно происходить абсолютно автоматически, с помощью библиотеки, а не чего-то о чем должен беспокоиться разработик приложения
— приложениям нужно записывать тот факт, что они отображают ресурс в каком-то определенном окне
— также им нужно записывать, что они перестали отображать его :)
— или окно, или ресурс должны быть ассоциированы с определенной сессий в момент отображения
— приложениям нужно говорить, когда им стоит закрыться
— приложения должны иметь возможность восстановить себя из данных сессии
— прложения должны иметь метод хранения своих собственных нестандартных данных в сессии
Это всего лишь основа основ, копирующая возможности XSMP. Чтобы сделать нечто действительно крутое, мы должны сделать еще и это:
— говорить приложению, какие именно окна нужно закрыть, если эти окна распределены между несколькими сессиями
— говорить приложению, должно ли оно возобновить всю сессию или только ее часть
— разрешать и поощрять приложения в том, чтобы они хранили общие переносимые данные сессии (такие как позицию в документе) в стандартном месте, и так, чтобы любое приложение могло воспользоваться этими данными
Уверен, что пропустил пару вещей, но вы уже поняли идею :)
На самом деле, существует и четвертая часть: синхронизация между устройствами. Как два устройства будут обмениваться своими данными сессии? Высылание списка ресурсов и связанных данных звучит чем-то довольно простым, но есть множество деталей, в которых еще стоит разобраться — какие ресурсы нужно копировать на другие устройства, как обходиться с изменением URI (файл /home/chani/Documents/foo.pdf на станционарном компьютере окажется на телефоне где-то в совсем другом месте), когда пытаться синхронизироваться и как разрешать конфликты… :) Уверен, есть люди, понимающие во всем этом гораздо больше меня. И, в качестве бонуса, получившийся код синхронизации должен быть готов для переноса между дистрибутивами, и даже, когда-нибудь, между большинством различных бэкендов для хранения данных.
Реализация всего этого займет время, адаптация займет еще больше времени. Это — проект на много лет. Но, если люди действительно чего-то захотят, все это вполне реализуемо.
