It was a great conference, though. :) At first I was feeling a bit out of place – the conference shirts didn’t come in ladies’ sizes (boooo!!) and it seemed to be lots of server stuff and kernel hackers, not desktop or UI stuff. But I met some friends, saw contour/plasma-active/whatever being demoed at the LFNW booth, made some new friends, and pretty soon it felt like a regular conference. :) I don’t feel like talking much about the talks (I’d have to look at my notes for that, and besides, Dafydd’s notes are far more detailed) but the intro to kernel hacking was great – I learned a lot from it, and felt a wave of nostalgia when the guy talked about compiling your own kernel. ;)

The party on wednesday was particularly awesome – lots of people dressed up for the 20′s theme, and there was much dancing. Thursday I managed to get to four different parties – three of which were officially part of the conference. :) I remember having some interesting conversations… but I never heard what happened to that little multicolour lamp in the end. :P

I didn’t get a WebOS touchpad, unfortunately – I was hearing about them selling out during the conference (and my sympathies to the HP guy who heard the announcement right *after* his big talk) – but I was in the right place at the right time friday afternoon, when they gave away some nicely framed linux posters. :) So now I need to actually get tools to mount stuff on walls, because “got linux?” is still hiding in a corner.

At first it seemed like all the job offers would be for kernel hackers too, but after checking the job-wall and talking to people I found several hiring – even some local companies. yay! :) So, I’ve been polishing up my resume the last two weeks too.

Now somehow my vacation time has slipped away – I’m not even sure where it went. Doh. We’ve only had the one month of proper summer here (which I missed a third of for the desktop summit), and already the leaves are starting to fall, and a little chill is in the air… and, school starts in a few days. My last semester. Wow.
Time flies…

The talks, the bofs, the parties – pretty much everything went well. Even the weather did give us a day or two of sun before going back to the scheduled rain and wind. ;) I was happy to visit Berlin again too – I only had time to get to one of my favourite restaurants, but I came back with lots of delicious things in my suitcase.

There were lots of good talks – which was not entirely a good thing, because I had to make some hard choices at times. I ended up in more community than tech talks – good stuff about how to do outreach to get more contributors and more diversity of contributors (which means not just more women, but more cultural diversity too). I learnt more about wayland and accessibility too (yay qt-at-spi!), and discovered that “session” is an ambiguous word – there are all sorts of lowlevel sessiony things that have nothing to do with documents or windows or tabs, and systemd is trying to clean them up. Some of the keynotes were fascinating – my favourites were the design talk and the toaster talk. :) Oh, and did you know you can use nepomuk to search within movies? OMGWTFBBQ.

Oh yeah, and I did a lightning talk too, explaining why we need to replace XSMP and advertising the bof session. When I asked how many people hated XSMP, there were far more hands than I’d expected. I didn’t know so many people knew what it was!

At sunday’s party I was surprised to discover how many geeks love karaoke. There was a great crowd, and about a one-hour wait for songs! Despite that, there was also dancing in the other room. :) I hear there was dancing tuesday night too – sadly I had a stomach ache that night. Later in the week I dragged a few people out for a smaller karaoke session with some local friends. I love having a private karaoke room; there’s no strangers taking up mic time, you get to sing lots, and it’s much easier to be completely silly about it. :)

The bof sessions started on wednesday – and I started it off with wonderful, wonderful sleep. After getting caught up on that, my stomach was a lot less mad at me, and I spent the afternoon in the intel appup session. Yay, tablet! :) My new exopc is sitting on my desk waiting for me to start hacking on it.

Thursday afternoon was my sessions bof. Unfortunately some people got lost on the way back from the daytrip and didn’t make it, but it turned out pretty well anyways. I knew there was far too much material to cover in one bof session, even a two-hour session, so I tried to keep the conversation on core matters… after a while, we discovered that there really is a lot of overlap between zeitgeist and session management – the apps that are starting to use it are sending it a lot of the info we need – and zeitgeist is gaining traction, so we may team up and just make some zeitgeist extensions to collect the session info. This would make it easier on app devs – instead of giving similar information to two systems, they’d just report it once and be done. :) When I get some free time I’ll go over the meeting notes properly and start looking into this more.

There were lots of other fun things going on – football, Jos’ cooking, amusing attempts to get rid of the excess summit stickers – but I don’t have much time to write, because I’m at LinuxCon right now. :) It’s nice when a conference is only 20 minutes from my apartment. Maybe I’ll blog about it next week – it’s been pretty good so far. :)

I’ve discovered that my kde.org email account has been randomly bouncing some email, for at least the last year. Meep. I’m going to go file a bugreport now, but in the meantime, if emailing me has failed, try again. Or use my gmail address (chanika).

Oh, and the desktop summit was awesome, I’ll write about it sooner or later :)

Update 2: It turns out systemd is solving an entirely different problem. :) there’s no overlap between it and sessions-as-in-restoring-windows.

I’ve been trying to write this blog post for months, and always hitting writers’ block or other distractions. So, screw it – I’m just going to start writing and see what comes out. :)

What this is about, is sessions, and XSMP, and wayland. Activities use XSMP, the X Session Management Protocol, to save and restore groups of windows. Before that, it was only used for the login session. It’s actually a better protocol than people give it credit for, and it served well for a few decades – but times have changed. If we want to move forward and do awesome things like sharing sessions between devices, we need something new. Even Activities as they are now push the limits of XSMP – there are a few ugly little hacks hiding in there that I’d prefer not to have. :)

Now, the key here is, if we’re going to replace an ancient-but-reliable technology with something new, we want the new one to be not just better but a lot better. Something worth switching to. Small issues like XSMP’s lack of autosave will be easy to correct; the big one is that it’s process-based. Session keys are handed out per-process, and when things get restored, they’re done by calling that particular binary with the session key as an argument. This is the source of two major pains; the first is that when a process has multiple windows (like konsole), you can’t properly put those windows in different sessions – so Activities have to do ugly things to hide this. The second, and larger problem, is that it’s ridiculously non-portable and opaque. What if the program’s binary gets moved elsewhere? what if the user switches to a competing app? And of course, their phone is not going to have the same programs installed as their laptop! Even if they have a meego phone and use Calligra on all their devices, the binary for the phone will be named differently. :P

So, what do we do? We make it resource-based! :) Store data in a standard place and standard format, so that the session manager, instead of seeing “this session had /usr/bin/firefox, /usr/bin/konsole and /usr/bin/okular” sees “this session has web pages X Y and Z, which this device last used firefox to open, with X and Y in the same window; two terminals, which this device last used konsole for; and foo.pdf on page 3, which this device last used okular for”. Then if okular isn’t available it can ask the system for a program that handles pdf, and when the user sends the session to their phone, it doesn’t matter that there’s a different pdf reader, or even that the phone browser doesn’t support tabs. Not only that, but if there were 20 urls open instead of three, the phone could go “whoa, that’s a bit much; I’ll just open the first three and display links to the rest somewhere.” And I could go “hmm, when the heck did I create an activity called ‘shambles’? wtf is in it?” and get an answer without actually having to load it. ;)

Another side of this is, well, the small stuff does add up. I just heard that OSX gained some decent session support; they’ve taken lessons from the iPhone and applied them to the desktop, making a system where it doesn’t matter if an app crashes – the OS may even kill it whenever it pleases – the session support is so good it’ll come back just as it was. I’d love to see that sort of solid session support in linux; KDE apps with XSMP are pretty good right now, but they could be better (and an autosaving protocol would go a long way towards fixing that).

Now, replacing XSMP isn’t an entirely new idea. Gnome people have been sick of XSMP for quite a while, although I don’t think anyone stepped forward with an alternative (and for their purposes, it does work, anyways). When I talked to the Nepomuk guys many months ago, about cross-device sessions, they had already thought of it – but decided the political side of it was too hard. They might still be right – we’ll see. But it’s worth a try. :)

So, what is the hard part, you ask? It’s the reason I stuck with XSMP for activities: a new protocol means persuading apps to support said protocol. XSMP’s support, while patchy in places, is at least decently widespread and un-controversial. A new protocol… well, I’m fairly sure KDE would embrace it, but I want it to be a part of gtk apps too, and pure qt apps, and meego apps, and even the weird proprietary fringe ones (like maple) someday. That is a challenge. :)

So how do we meet this challenge? First, we explain the benefits it brings – I hope I’ve done that well enough above. Second, we offer app developers a well-designed, easy-to-use API that’s had some feedback from actual app developers; just the other day I saw someone on IRC complaining about XSMP being confusing. :) Third, once we’ve got enough support to know this is worth trying, we show them a solid implementation that works (without any fatal bugs). Seeing is believing, right? Nobody wants to spend precious time writing code for a system before it exists, so we get the minimal feature set done, port a couple of apps, and show it off. Fourth – the secret weapon. ;) Wayland is gaining popularity, and when apps start porting to it, they may as well port to this too, right? Wayland doesn’t have any session protocol of its own, so this could be it. :)

So, who’s with me? :) The desktop summit is only a few days away, and surprisingly I will make it (yay!) so I’d love to have a conversation about this there. It’s the perfect place, after all, for something that aims to be cross-device, cross-desktop and all.

TL;DR: a resource-based session protocol would let us do really awesome things, so it’s worth the effort to replace XSMP

Now, I’m going to go into technical details below the cut (I have enough material to write a paper on this but for that damn writer’s block…)

…

So, technical details. right. What actually needs to be implemented? What API might it need?
There are three parts to it, all interlocking. First, the common storage area. This can actually come before the rest, because XSMP doesn’t say anything about how session data is stored; apps can start using it and still be started by an XSMP server, which is great for the transition time (it’ll be long. nothing this big changes fast).

Anyways… I haven’t done much research on storage. It could be stored in nepomuk/tracker/zeitgeist, or in text files like kconfig, or even in a registry (eek) – all that matters is that the system does its job well, and that all the apps on the device are using the same one. It might turn out that different backends are better for different devices – I don’t know, and I would love to hear information about the pros and cons of various approaches. Apps will be updating certain data on a regular basis – page number, position in a movie, etc – so I’d like numbers on efficiency too.

I do at least have a rough sketch for the format of the data, though. The vast majority of resources will be a URI of some kind (usually local or http) and a position within the document. the uri becomes the key, the location one of the fields. other fields will be the window it’s in (after all, windows are still the unit that window managers work with, and their position and size is important session data too), the program last used to open it, custom data fields for that program (preferably kept to a minimum), and perhaps data from other devices (either to help with decisions where this device is unsure, or in case the session is transported to a third device where that info could matter). Session data for windows would be written out, perhaps by the window manager… Really I need a whiteboard and other programmers to come up with good data structures, so I want to go over this in berlin, and I’m sure it’ll change once again during implementation. :) The most important thing is just to settle on some resource-based structure that works.

Second is the session manager. This is a program – likely a daemon, but not necessarily – that loads up the apps when a session is opened, and tells them to close when appropriate. If there is a user-interaction feature (“would you like to save this document?”), it would handle that too. This is what ksm-server currently does for XSMP. It’s actually not that much work, mostly reading and writing config files, but it’s complicated by the apps’ ability to request user interaction (stalling session-close) or even cancel it entirely.

Third is the application API, the part most developers will see. I want this to be good. I’m also wondering about backwards and forwards compatibility here; the XSMP protocol hasn’t changed in forever, but a new protocol will have changes, if only to fix bugs or correct design mistakes. Most apps will be sharing the same dynamically linked library, but should we worry about statically-linked ones? Hopefully we can come up with a design that is fairly robust against such cases. I’m reminded of dbus here; it specifies its wire format, which has the advantage that all apps speak the same language forever, but the disadvantage that they can never improve that format ever. :/

Speaking of dbus, one of the things I’m wondering is, how should the session manager and apps communicate? I think the storage should be written to as directly as possible, for efficiency (write-write conflicts will be exceedingly rare, if they happen at all, and I expect the same for read-write conflicts). We might want some sort of choking if the filesystem’s buffer’s aren’t enough; as a worst-case scenario, consider a dozen apps each updating their state every 10 seconds, out of sync; that could be more than a write a second. Hopefully there won’t be more than one or two apps doing regular updates like that (you can only watch one movie at a time, and even when reading there’ll only be one source of background music) but it’s something to consider later.

Whoops, I got side-tracked; I was meaning to talk about communication with the session manager. While upgrading ksmserver and kwin to support sub-sessions (aka activities), I discovered the hell of dbus timeouts. I’d rather not go down that road again, but I’m not aware of the alternatives. XSMP uses some ancient protocol called ICE, which seems to have close ties to X11; it’s not the only protocol with that name, though, so googling is a bit of a pain. In any case, I’d like to sever the ties to X11 so that this can be easily used with wayland too – what do they use for communication?

Wandering onwards (my wrist’s getting a bit tired now despite breaks), the api offered is partially defined by the features offered. I think that the first version should omit all but the most vital features; some, like user-interaction and cancellation of the session-close, I’m leaning towards abolishing altogether. This is 2011, not 1990; apps ought to be capable of behaving sensibly when it’s time to quit. Even kate now has swap files to recover data after a crash; those can be used just as well to restore a session. The only downside is they’re not so portable… that’s a problem for later, I think. :) Heck, I might even leave out the ability to put a window in N sessions at once; it does so complicate things, I’m not sure if it’s actually a worthwhile feature in activities, and it would still be possible to have the feature in activities by creating extra sessions under the hood.

So, what features are really needed?
-either the app or the window manager ought to record the size and position of windows. If it ends up being done in the app, it should be entirely automatic, within the library, not something the app developer needs to fuss with at all.
-applications need to record that they’re displaying a resource in a certain window.
-they need to record that they’ve stopped displaying it too. :)
-either the window or resource needs to be associated with a particular session when it shows up.
-apps need to be told when to close.
-apps need to be able to restore themselves from session data.
-apps need a method to store custom session data

That’s just the most basic of basics, mirroring XSMP’s abilities. To make the thing actually cool, we’ll also need to:
-tell the app exactly which windows to close, in case it’s spread across sessions
-tell the app whether it should restore the whole session or just a part of it
-allow and encourage apps to store common, portable session data (like the position in a document) in a standard place that any app can use

I’m sure I’ve missed a thing or two, but you get the idea. :)

Actually, there’s a fourth part to this, too: the device sync. How will two devices share their session data? Sending a list of resources and associated data sounds easy, but there are plenty of details to figure out – which resources need copying to the other device, how to manage the change of URI (a file at /home/chani/Documents/foo.pdf on my laptop will end up somewhere else on a phone), whether to try and resolve conflicts… :) I’m pretty sure there are people who have given this part more thought than me, though. And as a bonus, the sync code will come in handy for migration should a distro change to a vastly different storage backend someday.

All this is going to take time to implement, and even more time to be adopted. It’s a multi-year project. But if the people want it to happen, it can be done. :)

I, well, I’m actually on hiatus at the moment. That was (and is) an incredibly hard decision, but… well, it wasn’t fun any more, it felt more like a job. And when someone’s asshat regressions cause you physical pain, it’s time to take a step back. I’m sure Ivan and Marco will fix up whatever bugs are found, and add new awesome activities stuff too. :) I miss lots of KDE people (hugs!!!) but there’s some stuff I need to do for myself right now.

Anyways, that’s not what I’m here to talk about. There’s a little project I did in january that I never got around to blogging about. It’s part personal tool, part experimental sandbox. I suck at names, so I called it ContextJournal. :)

What is this? it’s a neat little app that automates away the tedium of my personal journal system. Running KDE trunk, and having a strange knack for hitting freaky PIM bugs, I end up with my most important things stored in plain text. It’s grown into quite a system, one file per day with ascii todolists and stuff – add to that the need to do timetracking on one project, and, well, a bit of automation does wonders. :)

Contextjournal allows me to keep the plaintext system – if I trash my kde or X I can still go back to using vim – but it adds improved organization, and context awareness (this is where the cool experimental bit comes in). It timestamps every line, and keeps a separate journal for each activity – naturally it switches when I switch activities. :) Once the journal part was stable I added the todolist on the right, which is controlled by irc-like commands. The commands are logged too, so finding out when I finished something is just a matter of grepping. :) Oh, and it starts on all activities by default, since it’s designed to be a systemwide thing.

Obviously the program isn’t much use as a journal to anybody but me. A normal person would probably want it to link into akonadi and/or nepomuk, and share the data with other apps, so that the todolist shows up in korganizer’s calendar n’stuff. :) However, it is useful as example code: it shows how to make an app activity-aware. It’s actually a pure-qt app at the moment too; I wanted to show that you don’t need any kde dependencies to write activity-aware code (*cough*firefox*cough*). I also wanted to have a testbed for some strange XSMP problems that only qt – not kde – has. I’m still not sure whether the bugs lie in Qt or in kde’s xsmp handling or in kwin, but my bet is on QApplication. :/

I have plans to add other shiny things, like an overview screen (or just “what now?” suggestions from the todolists) and grouped todos, but something distracted me and I haven’t gotten around to it yet. Maybe when I don’t have any essays to write. :P

Anyways, the ContextJournal source is here; if you’re thinking about adding activity support to something, check it out. And keep in mind that by now, the API for working with activities is probably in kdelibs; it’s a lot more convenient than having to make all those dbus calls yourself. :)

For this one, I focused on how I, personally, use activities. I got the impression that showing real-world usage might make it a bit clearer what I’m trying to do here. :)

You can probably hear me getting a bit tired at the end… I had to reboot twice and fix my damn volume control before finally getting that one, so yes, I *am* tired. :P

oh, and here’s the activity manager plasmoid I mentioned. :)