Introducing Project Silk

[Sebastian Kügler]

Hey everybody,

[Please direct replies to this email to the kde-silk list only to avoid too much 
cross-posting]

This is interesting for you, if you are

* a developer of an application that could be enhanced by online content
* a developer of an application that is integrating online content or services 
* a developer working on web technologies in KDE

If you didn't say "bingo!" to at least one of those points, skip this email.

During Akademy in Gran Canaria, Richard Moore and I sat down in a bar and dreamed up 
a fully web integrated desktop, what features it would offer to the user and what is 
needed to get there. Let me outline our departure position first and then talk about 
the goal we have in mind.

Many users have their data and online identity on the web. Web-based email clients 
are ubiquitous, "googling" has become the new term for finding information, web-logs, 
social networks, micro-blogging are widely used for all kinds of purposes. A large 
group of users uses a web browser 98% of the time (according to my own made-up 
statistics). 

Yet, the web experience we deliver in KDE leaves many issues, or rather missed 
opportunities. We have built a wonderful desktop, window effects that support running 
many applications at the same time in a -- for the user -- manageable way. We have 
created a lot of new possibilities for an ergonomic and beautiful desktop, and strong 
applications on top of that. Many developers want to develop KDE applications for 
non-desktop machine, such as smaller, mobile devices and media centers.

Basically, the two things that set the web apart are content and services.

Content is data, stored on the web (or in the cloud). Think of your emails, movies on 
youtube, travel information on wikitravel, schedules for the local transport system, 
restaurant menus and of course technical documentation on Techbase. The concept of 
content includes both, private (to the user, to a group of people) and publicly 
accessible content (for example websites such as wikipedia).

Services make the content data available, structure it, connect it and present it. 
These services offer the content in different ways, for example as (dynamic) 
webpages, some in a more machine-friendly form such as XML REST APIs, RSS feeds.

The client used to access the data through the service nowadays is the web browser. 
The current situation is that the service ships a complete application to the user. 
Web applications that get their data live from the server and present it in a 
JavaScript-controlled HTML page are the norm. One problem here is that it's for the 
service increasingly hard to anticipate what works for the client, a big detailed 
webpage might not fit on a small, hi-res screen with touch-screen input, small fonts 
and mouse-based navigation are both no-gos for a ten-foot interface with a remote 
control. There is also very little consistency in both, appearance and interaction 
for the user across different web applications.

Project Silk's goal is free the web from these limitations of the browser:

* Content from the web becomes easily accessible to applications and in extension to 
  the user
* Web applications become first class citizens on the desktop
* Local clients are enhanced by the web, the web experience is enhanced by local 
  clients' possibilities.

What is Project Silk NOT?

* It's not just a new library, Silk is a coordinated effort to work on related topics 
* It's not an attempt to drag developers away from their projects, Silk is a group of 
  people from different areas in KDE who share the similar goals
* It's not boring.
* A separate project. Silk is a KDE-wide effort, online content can be used in many 
  parts of KDE, and in fact it is already.

Good Silk examples are the web services framework in Amarok, OpenStreetMap 
integration in Marble, Photo uploads in Digikam, GetHotNewStuff for Plasma 
components. Silk overlaps with many parts of KDE. Konqueror, Nepomuk, Plasma, the 
Social Desktop, Akonadi and many individual applications.

The Silkiness Scale

The question "How silky is this application?" can be split up into a number of 
aspects:

* It uses data from the web (1 point)
* It caches data for offline usage (1 point)
* It is a native client to enhance web content (1 point)
* ... for more than one device (1 point)

What's the status?

Project Silk has just started, but not from zero. There are many parts in KDE that 
make applications silky already. Many of the technologies in KDE and Qt make silky 
applications very easy to do. There is very little coordination and sharing between 
those scattered bits and pieces, however. 
We've also produced some new, silk-driven code. In the Silk Git repo, there is a 
webpage thumbnailer, and a prototype of a standalone web application done by Rich and 
me. Some people have started working on Silk projects in other parts of KDE, such as 
Alessandro, who is working on an online video dataengine for Plasma. People such as 
Flavio have shown interest to put develop his QtJson library in the Silk repo.
The first code has in fact been written the morning after we started thinking about 
Silk, it's the wikipedia KRunner.

Where to go from here?

* A write-up of ideas from that bar in Las Palmas:
  http://techbase.kde.org/Projects/Silk
* Some of the code we've been working on:
  http://gitorious.org/project-silk
* Selkie experimental standalone web app:
  http://techbase.kde.org/Projects/Silk/Selkie
* Subscription page for the kde-silk at kde.org mailinglist:
  https://mail.kde.org/mailman/listinfo/kde-silk
* IRC channel: #kde-silk on Freenode

Thanks for listening so far. :)

-- 
Sebastian Kügler

    Nijmeegs Instituut voor Informatica en Informatiekunde
    - Security of Systems -

 http://www.codeyard.net | http://www.euroquis.org | GPG Key ID: 9119 0EF9 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090918/dd31c66d/attachment.sig