Introducing Project Silk

  Hey everybody,

(re-sent with correct sender address) [Please direct replies to this email to the
kde-silk list only to avoid too much cross-posting]

This email 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@... mailinglist:
  https://mail.kde.org/mailman/listinfo/kde-silk
* IRC channel: #kde-silk on Freenode

Thanks for listening so far. :)

--
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9

Hi Sebastian,

please be sure to monitor
http://www.w3.org/2008/webapps/wiki/Main_Page

reading your email, this struck me as nearly parallel. WebApps could
hugely benefit from a KDE implementation and you could find an even
more interoperable way of doing things.

If you have further questions, please don't hesitate to ask.

Best,
Rigo Wenning
W3C Legal counsel

On Friday 18 September 2009, Sebastian Kügler wrote:
[...]

>
> 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.
>

Hi Rigo,

On Friday 16 October 2009 10:48:08 Rigo Wenning wrote:
> please be sure to monitor
> http://www.w3.org/2008/webapps/wiki/Main_Page
>
> reading your email, this struck me as nearly parallel. WebApps could
> hugely benefit from a KDE implementation and you could find an even
> more interoperable way of doing things.
>
> If you have further questions, please don't hesitate to ask.

I've browsed through the pages you link, but it's slightly unclear to me what the
technical bits are. (The pages seem to be mostly about organisation issues.) It's a
bit hazy to me, how it's useful for us (while of course the more we can work within
existing standards the better).

Is there a write-up with example and more concrete information about implementations,
maybe?
--
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9

Hi Sebastian,

I don't have a camera ready primer for you. Look at the  
specifications in http://www.w3.org/2008/webapps/wiki/PubStatus

The charter of the Webapps WG is a bit broad, but it explains a bit,
what the Group is doing:
http://www.w3.org/2008/webapps/charter/

I will also ask back internally and give you further information if
there is anything significant. Note well this one sentence from the
charter:
The target environments for the Web Applications Working Group's
deliverables include desktop and mobile browsers as well as non-
browser environments that make use of Web technologies.

The latter is what you intend to do as far as I can see.

Best,

Rigo

On Friday 16 October 2009, Sebastian Kügler wrote:

> Hi Rigo,
>
> On Friday 16 October 2009 10:48:08 Rigo Wenning wrote:
> > please be sure to monitor
> > http://www.w3.org/2008/webapps/wiki/Main_Page
> >
> > reading your email, this struck me as nearly parallel. WebApps
> > could hugely benefit from a KDE implementation and you could
> > find an even more interoperable way of doing things.
> >
> > If you have further questions, please don't hesitate to ask.
>
> I've browsed through the pages you link, but it's slightly
>  unclear to me what the technical bits are. (The pages seem to be
>  mostly about organisation issues.) It's a bit hazy to me, how
>  it's useful for us (while of course the more we can work within
>  existing standards the better).
>
> Is there a write-up with example and more concrete information
>  about implementations, maybe?
>

On Friday 16 October 2009 18:32:11 Rigo Wenning wrote:

> I don't have a camera ready primer for you. Look at the
> specifications in http://www.w3.org/2008/webapps/wiki/PubStatus
>
> The charter of the Webapps WG is a bit broad, but it explains a bit,
> what the Group is doing:
> http://www.w3.org/2008/webapps/charter/
>
> I will also ask back internally and give you further information if
> there is anything significant. Note well this one sentence from the
> charter:
> The target environments for the Web Applications Working Group's
> deliverables include desktop and mobile browsers as well as non-
> browser environments that make use of Web technologies.

Alright, it's a bit clearer now. I'll keep an eye on it. It seems like it complements
nicely what we want to achieve with Selkie. Doing that based on standards by the w3c
makes a lot of sense.

> The latter is what you intend to do as far as I can see.

Well, Silk as we look at it influenced all of those three aspects.
--
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9

Sebastian,

this is not only a one-way street. Only following is not sufficient.
I would really like if Silk-developers would also provide feedback
to the working group, especially in the non-browser environment, if
something is missing or especially painful.

Best,

Rigo

On Friday 16 October 2009, Sebastian Kügler wrote:
> > The target environments for the Web Applications Working
> > Group's deliverables include desktop and mobile browsers as
> > well as non- browser environments that make use of Web
> > technologies.
>
> Alright, it's a bit clearer now. I'll keep an eye on it. It seems
>  like it complements  nicely what we want to achieve with Selkie.
>  Doing that based on standards by the w3c makes a lot of sense.
>

Hi Rigo,

On Monday 19 October 2009 15:17:54 Rigo Wenning wrote:
> this is not only a one-way street. Only following is not sufficient.
> I would really like if Silk-developers would also provide feedback
> to the working group, especially in the non-browser environment, if
> something is missing or especially painful.

Sure :) We can only barely keep our mouths shut if we run into something we need
fixed "upstream", so I think that is a given.

Thanks for the friendly invitation :)
--
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9