Introducing Project Silk
Sebastian Kügler
sebas at codeyard.net
Fri Sep 18 17:12:49 BST 2009
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: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part.
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20090918/dd31c66d/attachment.sig>
More information about the kfm-devel
mailing list