Будущее Активностей — сессии, переносимые между устройствами

    Этот пост является переводом вот этой написанной сегодня статьи.

    Пост приглянулся мне прежде всего тем, что автор приходит к идее общего хранилища данных, и затрагивает тренд кросс-девайсности, который раскочегарили последние изменения в 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 на станционарном компьютере окажется на телефоне где-то в совсем другом месте), когда пытаться синхронизироваться и как разрешать конфликты… :) Уверен, есть люди, понимающие во всем этом гораздо больше меня. И, в качестве бонуса, получившийся код синхронизации должен быть готов для переноса между дистрибутивами, и даже, когда-нибудь, между большинством различных бэкендов для хранения данных.

    Реализация всего этого займет время, адаптация займет еще больше времени. Это — проект на много лет. Но, если люди действительно чего-то захотят, все это вполне реализуемо.
    Поделиться публикацией

    Похожие публикации

    Комментарии 43

      +1
      А я-то наивно полагал что несуществующее слово «активности» ( равно как и «экспертиза» в значении… ни за что не догадаетесь — «опыт», равно как еще букет прекрасных несуществующих слов, коверкающих русский язык ) используют только в нашей компании.
        0
          0
          что вы хотели сказать этой ссылкой?
        +1
        А действительно ли оно несуществующее? Беглое гугление показало, что некоторые источники считают множественное число слова «активность» вполне допустимым, в частности используется в БСЭ, хотя другие считают, что её нет. По-моему, допустимость или нет зависит от того в каком смысле мы используем слово — если как характеристику другого предмета, то не следует употреблять, если как отдельную сущность (как в этом переводе), то вполне можно. А то получается: «жопа есть, а слова нет» :)
          0
          Это трансформированное английское слово «activities» ( транслитерированное, если хотите ) у которого на самом деле есть нормальный перевод. А у слова «активность» есть свое, совершенно иное, значение и нет множественного числа.
          Вот в данном случае ближайший по смыслу перевод был бы «сессии» и автор активно использует этот перевод вперемежку с «активностями».

          А вот результат моего беглого гугления:
          Толковый словарь русского языка Под ред. Д. Н. Ушакова.
          АКТИВНОСТЬ — активности, множественное число нет, женский род ( слово книжное ). Отвлеч. имя существительное к активный.
            0
            в терминах KDE есть разница между Activity и Session. Если перевести «активности» как «сессии», возникнет путаница
              0
              Значит нужно найти такой перевод слова Activity чтобы была разница между ним и Session, но при этом не пытаться изменить смысл существующих слов русского языка.
                0
                Если в языке не хватает слов, приходится придумывать новые ;)
                  0
                  Наверное, тут нужен тест.
                  Возьмем обычного пользователя KDE и просим, понимает ли он, что такое «активность» в контексте KDE.
                  Не понимает — значит перевод плохой, понимает — хороший.
                    0
                    Гениальное изобретение человечества — демократия.
                    Вообще, нужно бы памятник поставить тому кто первым понял что манипулировать толпой со средним индексом интеллекта стремящимся к нулю гораздо проще :)
                    • НЛО прилетело и опубликовало эту надпись здесь
                0
                >Вот в данном случае ближайший по смыслу перевод был бы «сессии» и автор активно использует этот перевод вперемежку с «активностями».

                всех человеков, переводящих технические термины «близко по смыслу» нужно долго и больно лупить по голове чугуниевым контекстом.
                  0
                  Я тоже думаю что нехрен трансформировать непереведенное в неудобоваримое неудобочитаемое.
                  0
                  Этот источник я упомянул под «другие». Но в других вполне себе академических источниках (на викисловарь уж ссылаться не буду) употребляется и во множественном числе. Например цитата из БСЭ
                  Эта величина принимается по определению равной произведению активностей ионов, на которые молекула распадается при электролитической диссоциации. За коэффициент А. сильного электролита принимают среднее геометрическое из коэффициентов активностей его ионов; коэффициенты А. ионов считаются равными отношениям активностей к концентрациям (так же, как в случае неэлектролитов).
                  Как видите это слово заимствовано в русский не только как «Отвлеч. имя существительное к активный» и не кдешниками и гуглофилами.
                    0
                    Там же есть определение понятия, использованного далее:
                    Активность термодинамическая, величина, характеризующая стремление вещества выделиться из раствора.

                    Это немного разные вещи, но судя по всему это результат одного процесса — человеческий мозг постепенно размывает границу между часто используемыми языками.
                    Там же:
                    Понятия «Активность» и «коэффициент Активность» введены в химическую термодинамику американским учёным Г. Н. Льюисом в 1907.

                    Но эта «активность» хотя бы не изменяет смысл самого слова.
                      0
                      А эта изменяет? И, имхо, корень в слове «активность» не похож на славянский, а значит слово и так заимствованное. Что плохого в том, что к одному заимствованному смыслу добавится другой заимствованный смысл?
                        0
                        А что плохого в такой строке "#define TRUE FALSE"?
                        Можете считать меня консерватором, но меня немного напрягают такие добавления.
                        В конце концов, если развить тему, то для создания нового языка вполне достаточно одного слова — ведь можно договориться что оно будет обозначать все на свете :)
                    0
                    Вообще-то, сеансы, а не сессии. Но это же такая мелочь, да? :)
                +1
                это же kde — опять родят нежиснеспособную сферическую херню, которую будут поддерживать полтора приложения.
                  0
                  Ну, внутри KDE и KDE PIM оно будет вполне жизнеспособно — ведь они его и пишут :) Вопрос, подхватят ли идею гномеры и просто гткшники. Та каноническая разборка с иконками в трее и радикальная позиция гномеров заставляет задуматься, как они дальше будут строить отношения с фридесктопом и кедами…
                  0
                  «Вейленд»… а почему не «Путьземля»?
                    +2
                    Потому что это имя собственное, имеющее германские корни, соответствующее немецкому Wieland, скандинавскому Völund и Vølund. Его можно транскрибировать, но его никогда не переводят на русский язык — нет такой традиции.
                    0
                    Звучит заманчиво. Но чтобы оно действительно было полезным (читай — чтобы производители приложений стали его использовать, вместо своих «поделок» с близкой функциональностью) и кроссплатформенным нужно прежде всего, имхо, разбираться с синхронизацией. Решений сейчас множество, но совместимостью между ними и не пахнет. К тому же многие из них платны или фримиум, вдобавок некоторые чуть ли не являются частью ядра и уже имеют свой API, позволяющий приложениям работать с ними на уровнем выше чем «симлинк на конфиг в „расшариваемой“ папке». Да, URI на локальный ресурс и данных о позиции в нём явно будет недостаточно — надо синхронизировать и сам ресурс либо работать только с удаленными.
                      0
                      А какие сейчас есть решения?
                        +1
                        По синхронизации между разными машинами (в том числе и под разными ОС) файлов? Полно, самый популярный, наверное, Дропбокс. Но даже если он предоставляет какое-то API, то привязывать к нему кроссплатформенное хранение и синхронизацию сессий явно не тру. Открывать разработчикам свое хранилище тоже не тру. Тру — дать пользователям выбирать место хранения синхронизируемых данных, хоть Дропбокс, хоть Убунту1, хоть гуглодоки, хоть в облаке от МС (вроде есть у них что-то тоже), хоть свой сервер поднимать, хоть через флэшку синхронизировать, предоставляя адаптеры с единым API между менеджером сессий и хранилищами. Кроме технических преимуществ это даст владельцам «облаков» зарабатывать на хранении и синхронизации данных сессий и не исключено, что они будут делиться с авторами приложений/дистров/ДЕ/ОС, чтобы те ставили именно их хранилище по умолчанию, что сподвигнет авторов использовать новый протокол.
                        0
                        >Да, URI на локальный ресурс и данных о позиции в нём явно будет недостаточно — надо синхронизировать и сам ресурс либо работать только с удаленными.

                        ну хоть кто-то заметил подвох!

                        вот кстати давно хочется такую штуку, которая хоть файлы нормально синхронизирует.

                        inb4 dropbox: не кромссплатформенно, не секюрно, негибко и вообще не особо умнее rsync.
                          0
                          ты просто не дочитал до конца статьи, там это есть ;)

                          скопипастаю тебе чтобы меньше искать:

                            0
                            На самом деле, существует и четвертая часть: синхронизация между устройствами. Как два устройства будут обмениваться своими данными сессии? Высылание списка ресурсов и связанных данных звучит чем-то довольно простым, но есть множество деталей, в которых еще стоит разобраться — какие ресурсы нужно копировать на другие устройства, как обходиться с изменением URI (файл /home/chani/Documents/foo.pdf на станционарном компьютере окажется на телефоне где-то в совсем другом месте), когда пытаться синхронизироваться и как разрешать конфликты… :) Уверен, есть люди, понимающие во всем этом гораздо больше меня. И, в качестве бонуса, получившийся код синхронизации должен быть готов для переноса между дистрибутивами, и даже, когда-нибудь, между большинством различных бэкендов для хранения данных.
                              0
                              Акцент на ней как-то не сильно сделан. Имхо, синхронизация и хранение неразрывны, если говорить о действительно широкой кроссплатформенности. Вот сложно представляется, как Micosoft будет рекомендовать девелоперам использовать zeitgeist для хранения данных сессии и настроек приложения, а UbuntuOne для их синхронизации. По-моему не хранилище нужно создавать прежде всего, а универсальный (но простой) API, по которому менеджер сессий и приложения будут с хранилищем взаимодействовать. Причём API нужен такой, чтобы Microsoft могла реализовать хранение в своем любимом реестре, синхронизацию в своём любимом облаке, а я — хранение на плоских файлах и синхронизацию rsync'ом и всё это прозрачно для приложений и менеджера сессий. Синхронизацию можно реализовать отдельным модулем, который будет работать с API хранилища, а можно вообще её сделать подсистемой системы хранения, тогда система хранения будет общаться только с менеджером сессий и приложениями (возможно через менеджер), а как будут храниться и синхронизироваться данные их волновать не будет.
                                0
                                Стоп-стоп-стоп, при чем здесь Microsoft?
                                  0
                                  Новый протокол… ну, я почти уверен, что в KDE им воспользуются, но хочется, чтобы когда-нибудь он стал частью приложений и на gtk, и на чистом qt, и на meego, и даже на кривых проприетарных поделках. И вот это уже — настоящее испытание! :)


                                  Выделенное разве не к винде с макосью относится? :-/
                                    0
                                    Гляди,

                                    1) Демон синхронизации — на Windows прикладывать самую последнюю версию к абсолютно всем приложениям, которые этого демона требуют. Собственно, так и происходит со всякими .NET и Visual C++ Redistributable Package, все инсталляшки тянут его с собой. Чтобы тянуть с собой бинарник помощи МС не требуется.

                                    2) Протокол от МС изначально не зависит. Он вообще универсальный и не зависит ни от кого.

                                    3) Локальное хранилище данных с поддержкой CRUD и источник ресурсов — реестр, NTFS и виндовая реализация сетевых протоколов всё это уже умеют, помощи МС _уже_ не нужно :)

                                    4) Синхронизация — раз уж мы говорим о том, что пользователь может свободно выбирать провайдера синхронизации, то в чем тут роль МС? В том чтобы впилить свой собственный провайдер по умолчанию?
                                      +1
                                      то в чем тут роль МС? В том чтобы впилить свой собственный провайдер по умолчанию?

                                      И это тоже. Вернее в этом её интерес. Но главное для меня :) — своим интересом она может обеспечить наличие реализации всего этого стэка на 90+% десктопов мира и этим простимулирует внедрение его в gtk и android…
                              0
                              UbuntuOne, которой я пользуюсь точно не кроссплатформенее, но хоть дешевле (и бесплатные лимиты больше, и платные дешевле при том, что шаг меньше). Плюс API и спеки открыты (только толком не понял их взаимоотношения с freedesktop и desktopcouch в частности, что в теории проблему кроссплатформенности снимает, но пока ещё «Windows coming soon», а про MacOS и вообще ничего…
                                0
                                дешевле свой UO поднять :/
                            0
                            Жаль, только, что самого Вейланда еще ждать и ждать, точнее мне даже сложно сказать, жаль или не жаль, потому как на данном этапе его развития не охота жертвоваться стабильностью пробовать Вейланд
                              0
                              > не охота жертвоваться стабильностью пробовать Вейланд

                              его пока нельзя использовать ни для чего кроме экспериментов, ни о какой стабильности в смысле работы в качестве основного инструмента речи не идет
                                0
                                ну я знаю
                              0
                              Надо признать, идея отличная и крайне интересная. У меня тоже были давно уже идеи, что современные ОС, во-первых, должны спрятать от пользователя запуск/останов процессов, либо через сохранение их состояния, либо просто тупо гибернацией ненужных процессов на диск. Во-вторых, сохранять состояние системы при падениях и перезагрузках, организуя таким образом непрерывный поток работы.

                              Но. К сожалению, в Линуксе за хорошими идеями и концепциями обычно идет дурная реализация. За примерами ходить далеко не надо: берем дистрибутив на основе KDE, и запускаем kwrite через strace. Через несколько секунд закрываем окно блокнота. И удивляемся размеру лога. С таким подходом к разработке Линукс всегда будет тормозить рядом с конкурирующими ОС.
                                0
                                kwrite это не показатель

                                линукс не благодаря ему стал популярной ОС
                                +1
                                Я думал о таких ограничениях xsm, ещё до 4х кед и дарю бесплатные идеи (я так понимаю, готового у вас всё равно ничего нет):

                                — в качестве «урлов» можно использовать что-то типа magnet ссылок, что бы указать не только локальный идентификатор ресурса, но и его «aka», например, в виде хэша от контента ресурса (либо вместо magnet использовать контейнер использованного вами хранилища). В этом случае можно будет организовать «открытие» частных документов даже между устройствами, используя локальную серверную инфраструктуру (в т.ч. контроль доступа).

                                — в хранилище менеджера активностей можно данные разбивать по классам: к примеру, можно хранить не только урлы на открытые приложениями ресурсы, но и контент (как оригинальный файл, так и последовательности диффов/undo), и даже дамп виртуального адресного пространства процесса приложения (или его виртуальной машины) запоминать. Соответственно, когда активность будет восстанавливаться, менеджер активностей будет восстанавливать то, что сможет. Т.е. если активность будет активирована на том же устройстве, на котором была деактивирована, то скорость восстановки сессии будет сравнима со скоростью восстановления из suspend-to-disk. На первых порах можно только заложить подобную фичу на будущее. В любом случае, нужно будет придумать что делать, к примеру, с куками — которые, с одной стороны, к определённому открытому ресурсу не относятся, с другой стороны, многие ресурсы без нужных им кук не откроются.

                                — учитывая последнее замечание из предыдущего пункта, имеет смысл генерализировать проблему и сделать механизм «storage facility», в котором будут привязки к юзерам/сессиям, который будет предоставлять прозрачный бэкап и репликацию в облака и на серверную инфраструктуру пользователя, а механизм восстановления сессий будет лишь частным случаем.

                                P.S. А вообще, мне кажется, лучше подумать и вместо горожения велосипедов улучшить xsm/ksm и их поддержку приложениями (что бы те же позиции окон поактивнее сохраняли).
                                  +1
                                  Я не хочу растраивать, но Шани — девушка :) Профиль на гуглоплюсе

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое