Future Activities - sessions portable between devices

    This post is a translation of this article written today .

    The first thing I liked about the post was that the author came up with the idea of ​​a common data warehouse, and he touched on the cross-device trend that the recent changes in Mac / iOS have unraveled.

    So, writes Chani Armitage.

    I tried to write this post for many months, and usually it ended with either a complete stupor, or some other misunderstanding. So, to score - I'll start writing, and then we'll see what happens.

    What I wanted to talk about was sessions, XSMP, and Wayland.



    Activities (KDE Activities) use XSMP, X Session Management Protocol, X-ray session management protocol. They use it to save and restore groups of windows. Previously, it was used only to resume a session at the login. In fact, this protocol is much better than usually thought of, and it has served excellently for decades - but times are changing. If we want to move forward and do cool things like general sessions for several devices, we need something new. Even in Activities, since they are now expanding the limitations of XSMP, there are many hidden disgusting crutches that are not needed.

    So, the key point is that if we want to replace the old, but reliable, technology with something new, then we want this something new to be not only better, but muchit's better. Something really worth moving on. Small problems like the lack of autosave in XSMP are easily solved; but there is also a big problem that XSMP is process-based. Session keys are mapped to individual processes, and when you need to recover, this happens by calling a specific binary to which the session key is passed as an argument. This is the root of evil; To begin with, when a process has many windows (such as a console), you cannot correctly scatter these windows in several sessions - therefore, Activities should do all sorts of muck to hide it from the user. Secondly, an even bigger problem is that such a method is ridiculously intolerable and opaque. What if the program binary has moved somewhere? What if the user began to use an alternative application to replace the old one? And, of course, the same programs are not installed on the user's mobile phone as on a desktop computer! Even if he has a phone on meego, and he uses Calligra on all of his mobile and non-mobile devices, the binary on the phone will be called differently. : P

    And what do we do? Let's use the resources! :) We will store data in a standard place in a standard format. So that the session manager, instead of seeing "in this session are / usr / bin / firefox, / usr / bin / konsole and / usr / bin / okular", sees "in this session are the web pages X, Y and Z last time opened on this device using firefox, with X and Y grouped in one window; two terminals for which konsole was used last time; and foo.pdf, opened on page 3, which was opened last time on this device using okular. " Then if okular is not available, he can request a program from the system to open pdf, and therefore, when a user sends a session to the phone, it does not matter that the phone uses another pdf reader, or even that the phone browser does not support tabs. In addition, if 20 pages are opened instead of 3 pages, the phone may say “oh, it’s a bit much; I’ll open only the first three, and I will display links to all the others in a special place. ” Or, for example, I can think: “why did I create an activity called 'some garbage?' What the hell is there? ”, And I can get an answer even without having to download this session.

    The other side of the coin is that little things decide. Recently I heard that OSX has added serious support for sessions; they learned from the example of the iPhone and applied their knowledge to the desktop. Now there is a system for which it is absolutely unimportant if the application suddenly falls off - the operating system can kill it whenever it wants - the session support is so good that the application will restore to the same state as it was before. It would be very nice to see support for sessions of similar quality in Linux too; in KDE applications, XSMP support is already pretty good, but it can be even better (and before that, the autosave protocol has a long way to go).

    Now, replacing XSMP is not some completely new idea. XSMP dwarfs didn’t like it for quite some time, although I don’t think that any of them took steps to create an alternative (and XSMP is suitable for their purposes anyway). When I spoke with the guys from the Nepomuk team many months ago about sessions being transferred between devices, it turned out that they were already thinking about it - but decided that the political part of such a project would be too complicated. They may still be right - let's see. But worth a try. :)

    So what is the difficulty, you ask? Here's the problem I'm stuck with in developing XSMP for Activities: having a new protocol means convincing applications to supportthis protocol. Support for XSMP, although not without problems, has recently become widespread and has caused very little resistance. The new protocol ... well, I'm pretty sure that they will use it in KDE, but I want it to someday become part of the applications on gtk, on pure qt, on meego, and even on crooked proprietary crafts. And now this is a real test! :)

    So how do we survive this test? To begin with, we will explain to everyone which buns he will add - I hope I described it well enough above. Secondly, we will provide application developers with a well-designed, easy-to-use API, this should trigger a reaction from developers who really do something; I saw a person in IRC recently swearing at XSMP :) Thirdly, as soon as we have enough sympathy to know that the result is worth the effort, we will show them a reliable implementation that will really work (without critical bugs). To see is to believe, right? Nobody wants to spend precious time creating code for a system that does not exist yet, so as soon as we make a minimum set of features, sport a couple of applications, we will immediately show it all. Fourth - secret weapon: ) Wayland is gaining popularity, and when applications start switching to it, they will be able to switch to our protocol too, right? Wayland does not have its own protocol of sessions; our protocol may become one.

    So who is with me? There are only a few days left before Desktop Summit, and, suddenly, I am its organizer (yahhoo!), And I would like to discuss there on the topics described above. After all, this is a great place for something that aims to be portable between devices, desktops, and whatever you want in general.

    TL; DR: a resource-based session protocol will allow us to do really cool things, so replacing XSMP is worth the effort.

    Now, I want to delve into technical details (I have enough material to write a whole work on this topic, if not for this damn bad writer’s syndrome ...)

    ...

    And, what are we talking about, technical details. What really needs to be implemented? What kind of API do we need?
    There are three interconnected parts. The first is shared storage. It comes first, because XSMP doesn't say anything about how session data is stored; applications can start immediately using this data, or continue to be launched by the XSMP server (this may turn out to be a good solution during the migration phase. It will take a long time. Nothing so big changes quickly.)

    Okay ... I didn’t study storage facilities very much. You can store it in nepomuk / tracker / zeitgeist, or in text files such as kconfig, or even in the registry (eek) - it’s really important that the system copes well with its tasks and that all applications on the device use only it. It may turn out that different backends are suitable for different devices - I have not figured this out yet, and I would like to hear some information about the positive and negative sides of various approaches. Applications will regularly update certain data - page normal, position in the film, etc. - so I would also like to hear about efficiency.

    At a minimum, I made a rough sketch of the data format. The main part of the resources will be some URIs (usually local or http) and a position inside the document. The URI becomes the key, and the position becomes one of the fields ... Other fields will be the windows in which this resource is located (in the end, the windows still remain the logical unit of the window managers, and their position and size are important session data), last used applications, their own data fields for the program (preferably, the smaller the better), and possibly data from other devices (to help with solutions that the device can’t cope on its own, or if the session is transferred to some devices where these the data will be him be meaning). Session data for windows will be recorded, perhaps by the window manager itself ... Really, I need a blank board and more programmers to come up with good data structures, which is why I am going to do this in Berlin. And I’m sure that even these decisions will change during implementation :) For a start, it’s important to build at least some resource-based structure that will work.

    The second part is the session manager. This is a program - most likely a daemon, but not necessary - that loads applications when a session is opened and tells them to close when necessary. If there are any interactive processes (“Do you want to save this document?”), This should also be processed. This is what ksm-server does for XSMP right now. In fact, it will not take much time, for the most part it will take to read and write configuration files, but everything is complicated by the ability of applications to request communication with the user (pausing session closure) or even cancel it entirely.

    The third part is the transparent API, the part that most developers will see. I want the API to be good. I would also like to have backward and forward compatibility; XSMP has never been changed, except to fix implementation bugs or design errors, but the new protocol will change. Most applications will have a shared dynamically linked library, but should we worry about statically linked? Fortunately, we came up with a design that handles such cases pretty well. I recall dbus; he describes a bus format that allows applications to always communicate in the same language, but there is a drawback - they can never improve this format. : /

    Speaking of dbus, is it one of the things that interests me, how should the session manager and applications communicate with each other? I think the repository should be written so as to be accessible as directly as possible, for reasons of efficiency (simultaneous write conflicts will be vanishingly rare, if at all, and I expect the same from simultaneous write and read conflicts). We can expect something like a sharp decrease in performance if the file system buffer is too small; in the worst case, imagine how thousands of applications begin to update their state every 10 seconds without any synchronization; it may turn out that more than one write operation per second occurs. Fortunately, there will be few applications, which will do such regular updates, one or two (you can watch only one movie,

    Oops, I strayed slightly; Let's get back to talking with the session manager. When I updated ksmserver and kwin to support sub-sessions (that is, activities), I got stuck in a swamp with decoupling timeouts in dbus. Most likely, I was not the only one to go this way, but I do not know any alternatives. XSMP uses some kind of ancient protocol called ICE, which seems to be tightly tied to X11; There are many protocols with this name, so googling it is pretty unpleasant. In any case, I want to break the tie on X11, so that it can be easily done with Wayland - what do they use there to communicate?

    Continuing to argue further (my hands are already tired of writing, despite the fact that I take regular breaks), the API is exactly set by the opportunities that it provides. I think that from the first version it is necessary to throw out all the possibilities, except for the most vital; such as chatting with the user and canceling session closure. I am inclined to cancel completely. Now is 2011, not 1990; applications should behave correctly when their time comes to close. Even kate now has swap files to recover from crashes; they can be used to resume the session. The only negative is that they are not so portable ... but I think this problem can be postponed;) Damn, I have to postpone even the ability to add one window to N sessions at the same time; it complicates things so much that I'm not so sure

    So what opportunities do we really need?

    - the application or window manager should record the size and position of the windows. If in the end the application will do this, this should happen absolutely automatically, with the help of the library, and not something that the application developers should worry about
    - applications need to record the fact that they display the resource in a certain window
    - they also need to record that they no longer display it :)
    - or a window, or resource must be associated with a specific session at the time of display
    - applications need to talk when they should be closed
    - applications must be able to recover s themselves from the session data
    - applications must have a method of storing their own non-standard data in a session.

    This is just the basis for copying XSMP capabilities. To do something really cool, we must also do this:
    - tell the application which windows to close, if these windows are distributed between several sessions
    - tell the application whether it should resume the entire session or only part of it
    - allow and promote applications in so that they store the general portable session data (such as the position in the document) in a standard place, and so that any application can use this data

    I’m sure that I missed a couple of things, but you already understood the idea :)

    In fact, there is a fourth part: synchronization between devices. How will the two devices exchange their session data? Sending a list of resources and related data sounds somewhat simple, but there are many details that still need to be addressed - which resources you need to copy to other devices, how to deal with changing the URI (file /home/chani/Documents/foo.pdf to the stationary computer will be on the phone somewhere in a completely different place) when trying to synchronize and how to resolve conflicts ... :) I’m sure there are people who understand much more about this than me. And, as a bonus, the resulting synchronization code should be ready for transfer between distributions, and even, sometime, between most different backends for storing data.

    Realization of all this will take time, adaptation will take even more time. This is a project for many years. But, if people really want something, all this is quite feasible.

    Also popular now: