The Open Web: KDE frees the web from the browser [LWN.net]

October 14, 2009

This article was contributed by Koen Vervloesem

In recent times, the KDE project has been at the forefront of integrating the web into the desktop. In mid-September, Sebastian Kügler announced Project Silk. Meanwhile, Frank Karlitschek has been working on the Social Desktop for some time now.

On October 29, NLUUG holds its Fall Conference with the theme "The Open Web", where both KDE developers will give a talk. Sebastian will talk about freeing the web from the browser, while Frank's talk will be about the Social Desktop integration of web communities into desktop applications. Your author asked them to give a preview of their talks in an email interview.

Free the web from the browser

Sebastian will talk about the differences between the web as we use it now and what he calls "local clients": "My plan is to show how we can make the web more accessible for a multitude of different devices, and how we can tackle this." This is all part of his Project Silk, which has, as its ultimate goal, a close integration of the content and services of the web into the KDE user experience.

To see why it makes sense to integrate web content into a desktop environment, we have to take a birds-eye view on the evolution of web browsers in the last couple of years. Then, we see that the web browser is now actually a very general platform: it evolved from a simple HTML viewer into a runtime environment for web applications that provide online services. What didn't change is one core assumption, according to Sebastian:

Most of these applications are written for one target device. This device has a screen of, let's say, 1024x768, a keyboard and a mouse and is always online. This has been a reasonable assumption for some time, but is becoming less and less of a given.

Indeed, if we look at our current use of the internet, it's much more varied than before: from mobile phones and internet tablets to netbooks, laptops, desktops, and media centers. Assumptions that were true when we accessed web services five years ago are simply not true anymore, Sebastian explains:

Now the user might have a spotty internet connection, which is often the case when you're using mobile devices on the road. Screens might not be big enough to show a full web application: on netbooks, screen real estate is very sparse, so we need to make better use of it. On the other side of the scale, it makes a lot of sense to enjoy online content on media centers, think of watching online videos from services like YouTube from your comfortable chair.

So in all those new use cases, the assumptions that websites make fall short. Reading small text is often impossible on large but low-resolution TV screens, a remote control or a touch screen behaves completely differently than a mouse or touch pad. Those capabilities of a device are best known to the client, so it's much easier to control these input mechanisms for web applications on the client. But there's more:

By not restricting web applications to a web browser, we can use the client's technologies to do really interesting things with the data on the desktop. The semantic desktop features that are integrated into KDE can greatly enhance the ease of use of information, on the local machine, but also on the web — and connect and combine those bits of information.

Of course using a native client to display online content provides a more coherent user experience when you're on the web from your desktop. Last but not least, Sebastian sees a security advantage: by separating content and client-side application logic from each other, it should be easier to build safer web applications.

Many things in the pipeline

Project Silk doesn't come out of the blue: KDE has already integrated many online sources into applications. For example, Sebastian has worked with Frank and others on components that integrate social networking into KDE's Plasma desktop shell. So we have already a lot of online content, such as email, contacts and social networks, integrated into desktop applications. But Sebastian admits that most of these efforts are rather cluttered and do little in the sense of sharing code, ideas, or infrastructure.

Most KDE applications are already fully network-transparent: they use the KIO API that allows a user to access remote files using the same methods as accessing local files. Moreover, in recent years some interesting services have been built: with Akonadi KDE has central cached storage for PIM data such as emails, contacts and calendaring. Nepomuk provides the basis to handle all kinds of metadata on the KDE desktop. According to Sebastian, these services are a powerful base to build applications that are "vastly superior to JavaScript-driven browser applications."

One of the first components in project Silk that KDE developers have been working on is Selkie, which turns a web application into a first class citizen of the KDE desktop by providing better integration with the window manager, integration with desktop services such as the notification system. and custom, per-web-application actions:

We've written a promising prototype and the idea seems to work surprisingly well. We have working test cases to manipulate the inner workings of a web application from the toolbar by injecting JavaScript into the running web application. This is a surprisingly easy way to give back some control to third parties on how web applications look like and behave on the desktop. I'll demo the prototype of Selkie during my talk.

More things in the pipeline include components to integrate online multimedia content into the KDE Media Center components. Sebastian also lists some lower-level activity going on, in the form of QJSon, a small library for the JSon protocol, classes to search and access content from MediaWikis such as Wikipedia, a thumbnailer for web pages, and so on. Because many applications that make KDE "silk" are integrated into the applications or Plasma, there is no central point with Project Silk code, but there is a git repository that collects the bits that aren't integrated yet.

The Social Desktop

Frank's talk at the NLUUG Fall Conference will be about the idea and the status of the Social Desktop in KDE, which he first proposed in his keynote speech at the 2008 Akademy in Belgium. The core idea of this project is to bring communication and collaboration in online communities to desktop applications, taking away the need to surf to forums and social networks in a browser. During his talk, Frank will give an overview of all the new features and possibilities from a developer and a user point of view. There is already work in-progress:

We have already implemented the means to find other KDE users near you, management of your friends, messaging, content sharing, knowledge base access and more. During my talk, I will give a more complete overview. We will have really good integration in KDE 4.4, which will be released in January. The access library for all the Social Desktop features will be moved into the KDE libraries and all the identity management will be a central part of KDE, so all KDE applications can access this social aspect very easily. We already have several applications that use these new possibilities.

So the point of the Social Desktop is to connect people to each other and bring them closer to the KDE desktop project and related topics. Frank stresses that this is not only useful for developers, but also for regular users: "For example, you can get in contact with other KDE users and can see what your friends are doing. Or you can get help via the Knowledge Base Integration without the need to open up a browser."

To be able to use social networks on the KDE desktop without tying the Social Desktop to one web platform like Facebook or Twitter, the developers worked on support for the open collaboration services (OCS) standard, which is an open standard published on freedesktop.org. According to Frank, several websites have already committed to supporting this specification so that users can choose from different data sources:

A social desktop should be independent so the users can use different "service providers" and there is no lock-in. Because of this, it is important to have an open and independent API specification so that different clients and different servers can understand each other and speak the same language.

Just like Sebastian said, Frank explains that there's nothing wrong with the browser per se, but if you integrate web services directly in desktop applications you can get a richer experience:

One example is an education application you use to practice your vocabulary in a different language. You get automatically a list of other people who want to learn your language and speak the language you want to learn. So you can connect and learn together. You can't get this with a standard desktop application. But you also can't get the richness and performance with a web application. A social desktop application combines both.

Social Desktop Contest

This brings us to the winners of the Social Desktop Contest, which was started on 17 June 2009. The goal of the contest was to foster community development and innovations around the OCS API. The winners of the contest were recently announced. In the announcement, Frank wrote:

There have been many new ideas and innovations coming from the community in the Social Desktop area and we received a large number of really good submissions. This made it obviously hard for the jury, as you can have only so many winners.

The winning submission of the contest is an ExtendedAboutDialog for KDE apps by Téo Mrnjavac. It gets information about the developers of a program — for example contact details, web addresses, and nationality — from opendesktop.org and shows it in the "About" window. This gives the application a human face and enables direct interaction with the development team. The extended about dialog can be used in any KDE application and already ships with Amarok 2.2.

The second place winner is the Knowledge base widget by Marco Martin. This is a plasmoid that lets users query the online opendesktop.org knowledge base without the need to visit a forum or subscribe to a mailing list. The widget will be part of KDE 4.4. The third place is for libopengdesktop by Guido Roberto. This is a simple Glib-based library that gives easy access to Open Collaboration Services providers. It will be useful to bring the Social Desktop to Gnome and XFCE platforms. The fourth place is for PyContent, a plasma widget written in Python to show the newest contents in specific categories from a content provider.

Open projects for an open web

Both projects, the Social Desktop and Project Silk, have a very open attitude. The idea, the server side and the API specifications of the Social Desktop are completely platform independent, Frank stresses:

We are developing a KDE specific client library at the moment, but it is possible to integrate this functionality easily into other applications or desktops. Proof of this is that one of the winners of the Social Desktop Contest developed a library to integrate this easily into GNOME. Gwibber, a GNOME Twitter application, has already support for the API.

At this moment, project Silk is still KDE-specific, but this has its reasons, Sebastian explains:

We are not yet in touch with other desktop environment's developers for cross-desktop developments. One reason is that we first want to have something in our hands. Going out and talking about lofty ideas often costs a lot of time. In this phase, Silk is an internal thing to KDE, we first have to collect and streamline our efforts, and work on a couple of things we think we are missing.

Contribute to an open web

Both projects are also open for contributions. KDE developers and users can get involved easily in the social desktop project. There is a mailing list, a wiki, the specification is available on freedesktop.org and of course all the KDE code is available in the KDE svn. Frank adds that there will be a developer meeting later this year specially for the Social Desktop: "Everybody is welcome. So please send me an email if you want to participate. It isn't important which desktop or technology you use. The Social Desktop is a completely open project."

Project Silk is very much an umbrella for people that work on web integration components, so it's not a closed group of people but, instead, consists of a number of people from all over KDE that have already been working on web integration aspects. That's why it's easy to contribute, as Sebastian notes: "Developers that find these ideas interesting should get in touch with us on the #kde-silk IRC channel on the Freenode.net network, or via the kde-silk@kde.org mailing list. We've spent some time documenting ideas about Project Silk on Techbase, KDE's knowledge base wiki."

All in all, both projects are still in their infancy, which is an interesting opportunity for open source developers who want to do some innovative work. The submissions to the Social Desktop Contest and the Project Silk ideas on Techbase are good sources for inspiration.

(Log in to post comments)

The Open Web: KDE frees the web from the browser

Posted Oct 15, 2009 15:14 UTC (Thu) by boudewijn (subscriber, #14185) [Link]

I'd be happier if people stopped posting "Oh no! They didn't fix my favourite issue and are working on something else instead!" messages whenever a free software, volunteer-based project shows some initiative.

Guess I won't get my wish either, but I cannot do anything about the whining of people who show a basic lack of understanding how volunteer- bugs you feel strongly about.

(And, for the record, I'm using screen in konsole every day, all day long, and I don't recall having a problem. Not to say you're whining about something non-existing, but I guess that the konsole developers (all two of them, and none of them are involved in project silk) don't have that problem either. So, if you want to be happy, it's up to you to scratch your itch, or to pay someone to fix the problem. And I wouldn't even have a clue about what you mean with the other problems you mention, so they probably don't hurt all that many people.)

The Open Web: KDE frees the web from the browser

Posted Oct 15, 2009 17:54 UTC (Thu) by nye (guest, #51576) [Link]

This kind of flaming does nobody any favours, least of all the reputation of the KDE project.

FWIW, the features the OP would like would be extremely difficult (I think impossible) to implement without modifications to screen, except possibly using some deeply ugly hacks, however I do have the following in my bashrc, which the OP *might* find of some use:

function ssh-reagent () {
    for agent in /tmp/ssh-*/agent.*; do
        export SSH_AUTH_SOCK=$agent
        if ssh-add -l 2>&1 > /dev/null; then
            echo Found working SSH Agent:
            ssh-add -l
            return
        fi
    done
    . ~/.ssh-agent
    if ssh-add -l 2>&1 > /dev/null; then
        echo Found working SSH Agent:
        ssh-add -l
        return
    fi
    echo Cannot find ssh agent - maybe you should reconnect and forward it?
}

The Open Web: KDE frees the web from the browser

Posted Oct 15, 2009 18:49 UTC (Thu) by boudewijn (subscriber, #14185) [Link]

Flaming? I wouldn't call what I said flaming -- just expressing being fed up with people complaining about completely unrelated things in reaction to announcements.

It's quite the fashion these days to make that sort of remark, but it makes me sick. And it shows a complete lack of understanding of the way a large volunteer-driven free software project works: it is made up of many individuals, who all work on what they find interesting, and any request to reallocate effort from one sub-project to another to gratify the poster is mere pointy-haired-bossiness. Fine, this subproject is of no interest to Mtk -- what's the problem? There are tens of thousands of projects that don't fix Mtk's bugs -- will he or she post a complaint with every announcement?

If mtk is interested in terminal emulation, he or she should get involved. I know it's an unpopular message these days, but it's the only way forward. Pay up or submit patches but don't whine in the comments section of a website.

The Open Web: KDE frees the web from the browser

Posted Oct 15, 2009 19:05 UTC (Thu) by mtk (subscriber, #804) [Link]

any attention (even negative) from someone on the inside is good. no need to rehash the eternal complain vs contribute argument. my point was this: at the end of the day, merging screen into konsole (and into gnome-terminal) would have a greater impact on my every day use than deploying a browser-independent social networking desktop. a power user argument for sure, and thus not generally applicable. but this is LWN after all :-).

The Open Web: KDE frees the web from the browser

Posted Oct 15, 2009 20:13 UTC (Thu) by boudewijn (subscriber, #14185) [Link]

I work on a suite of KDE applications, that's true, but I'm no more on the
inside of konsole development or project silk than you -- and I still
don't get why you ask for bug fixing on konsole instead in response to
this announcement instead of, say, an announcement of the next KOffice
beta or Gimp release.

The Open Web: KDE frees the web from the browser

Posted Oct 20, 2009 5:16 UTC (Tue) by k8to (subscriber, #15413) [Link]

Without any comment on the state of any KDE projects, it is kind of frightening how there's almost no quality terminal maintained anymore.

Xterm works fine, but has really wonky ui, worst part is broken scrollbar.

rxvt: dead

urxvt: features in perl....

mrxvt: kind of cargo cult

gnome terminal and backing library: paste bugs, fat

konsole: don't know this one as well, but the list of dependencies is long -- dont' really need a lot of stderr spew from my terminals.

the best of the lot is urxvt, but more love for terminals would be nice, given how important they are.

The Open Web: KDE frees the web from the browser

Posted Oct 20, 2009 6:03 UTC (Tue) by foom (subscriber, #14868) [Link]

I've been using konsole with my otherwise gnome desktop for a long time now, and I've been quite
happy with it. I switched when gnome-terminal was crashing all the damn time. Furthermore g-t
didn't have a "find in history" command. (it may now -- haven't looked back).

I don't know how I ever lived without "find" in my terminal!

The Open Web: KDE frees the web from the browser

Posted Oct 17, 2009 12:59 UTC (Sat) by sebas (subscriber, #51660) [Link]

Well, read again: "Last but not least, Sebastian sees a security
advantage: by separating content and client-side application logic from
each other, it should be easier to build safer web applications."

Apart from that, the interview was long enough as it is, so we didn't dive
deeply into security issues (which is another pretty wide topic). If
you're interested in security aspects in project Silk, I'd encourage you
to join our mailinglist, or if you're more into hands-on stuff, feel free
to help us review code.

For the social desktop applet, we've decided to not automatically update
the location of the user on the server, but have the user do that by
pressing a button. That said, any website can find out the rough user's
location just by using the agent's IP (sent to the server in the HTTP
request) and then matching it against iplocationtools. For the Selkie
browser, we're currently playing with separate processes per webapp, we're
looking into separating password and cookie storage, and so on. There's
surely some interesting things we can do security wise, but as I said,
it's more tied to a specific case than to overall ideas (since those ideas
touch many different layers). Just shouting ".... eh security!!!!111"
doesn't really add a lot at this point.

re: ActiveDesktop ... can't say I care too much about this, or that I ever
actually used it. What exactly are you hinting at? (Hint: Silk has a much
broader scope than merely the desktop.)

The Open Web: KDE frees the web from the browser

Posted Oct 17, 2009 22:57 UTC (Sat) by pflugstad (subscriber, #224) [Link]

I read the article, and saw the comment about separating content from client-side application logic. And honestly, I'm not entirely sure what that means. The problem with most of the web is malicious content that exploits holes in the client side application. The more client side web applications there are, embedded EVERYWHERE as this seems to be, the more places malicious content has to look for exploits.

I know you're not trying to recreate Java/CLR, or even JavaScript, but in order to be compelling over browser based content, your application is going to have to provide content with similar features and ability to interact with the desktop.

And, to make an example: some malicious content crashes one applet, and now, thanks to the centralized identity management, it has access to ALL my online passwords, emails, etc. Yes, this is possible today, but the diversity of locations and mechanisms makes it much more difficult.

And that doesn't answer the other half of the security question: how secure is MY data when it's on the "web". This is where facebook falls flat - give one facebook application access to your data, and they get access to ALL your data, and your friends data and your friends friends data, or some such nonsense. Security was clearly an afterthought on that social network site. Is any thought being given to how to put up boundaries around the information we provide to the myriad of applets and web-integrated desktop you're creating.

W.r.t my ActiveDesktop comment: Microsoft tried to "integrate" the web into the desktop, 10 years ago. It flopped massively: it was a performance pig, and was just an incredibly bad idea from just about any angle you care to look at. I don't know that anything has changed in the last 10 years to make it any better of an idea - if anything, the increased threat level makes it a worse idea. So now when I fire up the KDE desktop, I'm going to get 10 more "applets" that chew up system resources, and if even one is unstable and causes problems, suddenly my whole desktop drags. Oh, and if some web server one of those applets goes to is compromised and serving up actual malicious content, the applet may crash and suddenly some cracker controls my desktop.

I guess my whole point is that security CANNOT be an afterthought on this kind of stuff. It needs to be thought about up front and included in every stage of development. My other point is that integrating the web into the desktop has been tried before... And while my shouting security may not be terribly helpful, hopefully it raises your awareness of it, and possibly others on this site.