|
|
Log in / Subscribe / Register

KDE's Project Silk

[Posted September 21, 2009 by corbet]

From:  Sebastian Kügler <sebas-AT-kde.org>
To:  kde-silk-AT-kde.org
Subject:  Introducing Project Silk
Date:  Fri, 18 Sep 2009 18:43:19 +0200
Cc:  kde-devel-AT-kde.org, kde-core-devel-AT-kde.org, plasma-devel-AT-kde.org, kfm-devel-AT-kde.org

  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@kde.org 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

to post comments

KDE's Project Silk

Posted Sep 21, 2009 20:37 UTC (Mon) by kragil (guest, #34373) [Link] (21 responses)

This is great, but not nearly ambitious enough.

I want a P2P desktop. A people to people desktop. I want all apps to be aware of my social network and I want all communication to be serverless and encrypted. No proprietary web service in between.
Retroshare.org is a very good effort in this direction but it does not really integrate into any desktop environment.
Examples for people with no imagination:
I want to share parts of my music collection with specific friends, I want to invite a coworker to help me write a document in KOffice, I want an encrypted Facebook-like profile saved in P2P cloud etc.
And to accomplish this I only want to exchange a key with my friends, the rest (UPnP port forwarding etc) should just work without any config.

KDE's Project Silk

Posted Sep 22, 2009 1:08 UTC (Tue) by coriordan (guest, #7544) [Link] (19 responses)

The availability of those features would probably be great, but I hope the KDE and Gnome devs also keep in mind that some people don't use any computerised social network thingies (centralised or not), and some people don't want any personal information shared without explicit, clearly delimited permission.

KDE's Project Silk

Posted Sep 22, 2009 9:10 UTC (Tue) by kragil (guest, #34373) [Link] (15 responses)

I don't think you will ever be forced to use it.

But what I see is the increased reliance on proprietary websites. Even opendesktop.org and all its sibling sites are not FOSS as far as I can tell and they are everywhere in KDE, even most of the new social network features are closed source on server site. I am not 100% sure, but it looks like they are. And this is although they are run by KDE people.
I don't like it when people on the one hand encourage everybody to use identi.ca instead of Twitter and then combine their desktop with a lot of other proprietary webservices. FOSS should only rely on FOSS PERIOD

KDE's Project Silk

Posted Sep 22, 2009 10:47 UTC (Tue) by ballombe (subscriber, #9523) [Link]

The problem is not only that the server code is not FOSS, but also that such community site should be managed by its own community. It should belong to a non-profit whose members are the community members, with voting rights.

KDE's Project Silk

Posted Sep 22, 2009 11:52 UTC (Tue) by sebas (guest, #51660) [Link]

The idea is indeed to create interfaces for service-types (think of social-networking, web-shopping) as examples. Those APIs are independent from the service they interact with. Applications use these APIs to offer integration with webservices.

These APIs are backed by plugins. So a social-networking API would have plugins for facebook, opendesktop, linkedin, for example. The application developer doesn't care about which particular service is being used. The plugins that are backing the task-specific API are written using script languages, or are generated from webservice descriptions (if possible). The API also doesn't discriminate between free and non-free services. Using scripted plugins makes it easy to update these plugins whenever the web service interface changes.

Which services are offered depends on what plugins are provided. Of course it's easier to write such a plugin for a well-documented interface (think of a REST API like openDesktop) than for a closed service -- it'll become easier to use the service from silk-enabled applications if the service makes its content and interaction available in a documented, machine-readable way. Those plugins could also do screen-scraping as a last resort for less friendly web services.

The question how we, as a Free software project protect our Freedom is only loosely connected to this. The idea is to have three categories: open, free and ugly.

- "free": Free web service implementation (such as identi.ca, openstreetmap)
- "open": Documented interface, service is not necessarily free but has a stable, machine-readable API
- "ugly": closed and no openly documented interface

Obivously, we prefer and actively encourage "free" and "open" services, but there's nothing that stops people from implementing backends for "ugly" services.

KDE's Project Silk

Posted Sep 22, 2009 13:21 UTC (Tue) by anselm (subscriber, #2796) [Link] (9 responses)

I don't think you will ever be forced to use it.

Who knows? I'm already forced to run a completely extraneous MySQL server for no discernible benefit. It's as if the KDE-PIM developers have never heard of SQLite.

KDE's Project Silk

Posted Sep 22, 2009 13:44 UTC (Tue) by sebas (guest, #51660) [Link] (8 responses)

Akonadi (which is what you're probably referring to) *currently* requires
MySQL, its storage is abstracted so you could plug in a different storage
engine, however. The requirement is as simple as "right now mysql is the
only backend".

During the beginning of Akonadi development, the idea was to actually use
sqlite, but it was very problematic. Sqlite could not, at that point
handle the number of concurrent queries such a high-performance cache
would need, it also wasn't thread-safe.

It seems that sqlite has improved in those areas, and work on an sqlite
backend is well underway. There's also work going on on a postgresql
backend, by the way.

All that has nothing to do with forcing people to use certain webservices,
of course.

KDE's Project Silk

Posted Sep 22, 2009 20:56 UTC (Tue) by anselm (subscriber, #2796) [Link] (7 responses)

The problem is really when people like the KDE-PIM developers have their own notion of what is good for everybody and then proceed to cram whatever that is down everyone's throat. I'm a big fan of »Heuer's Law«: »Any feature that cannot be turned off is a bug.«

I don't *need* an SQL server to store a few hundred addresses. My machine is running an SQL server but I need that for other things (such as software development), and I certainly don't want my desktop environment to mess with it. Neither do I want the overhead of another MySQL-size daemon just for a bunch of PIM data (my machine isn't *that* big). Akonadi might be a great idea if it was optional, or if there was a backend that catered to people who need only very basic functionality, cheaply. I'm generally happy with KDE but this tendency towards a fixation on infrastructure for infrastructure's sake makes me look for alternatives.

KDE's Project Silk

Posted Sep 22, 2009 22:15 UTC (Tue) by sebas (guest, #51660) [Link]

Akonadi is not about MySQL, or a daemon of its size. Akonadi is about
providing a common synchronization and access layer for PIM data.

Even if you only store three emails in it, it still makes sense to make
them accessible for your applications other than the primary email client.
You also don't want to rewrite all the email protocols over and over, for
every new email application. That's what Akonadi takes out of your hand.

As I said, an sqlite backend is under way. That would be the one catering
to those very simple use cases you're talking about. It has only become an
option very recently, due to technical issues with it (see other comment).

KDE's Project Silk

Posted Sep 23, 2009 5:33 UTC (Wed) by dkite (guest, #4577) [Link]

I think you have it backwards. Akonadi has had very limited usage within
kde, gradually increasing as apps are ported to use it. In other words, the
ideas were implemented using tools that worked at the time. Proof of concept
type thing. As it becomes more useful, more integrated, the availability of
suitable backend libraries hopefully improves at the same time. But the
necessity of getting something out there for people to bang on forces bad
choices.

Really, all this episode shows is that for serious desktop work, developers
run into serious limits and sometimes walls that gives them the choice of
writing from scratch or using something inappropriate. In this instance due
to the lack of a lightweight full featured data/storage/retrieval engine.

Derek

KDE's Project Silk

Posted Sep 23, 2009 10:38 UTC (Wed) by segedunum (guest, #60948) [Link] (4 responses)

Ahhhhh. The whining refrain from someone complaining about 'bloat' on his machine. Quite frankly, most users want their desktops and applications to actually do things and they don't care about you. Nobody is interested in whether *you* don't think you need a SQL server. If you're that bothered then go and write something yourself. Some light reading:

http://www.joelonsoftware.com/articles/fog0000000020.html

KDE's Project Silk

Posted Sep 23, 2009 11:02 UTC (Wed) by nye (guest, #51576) [Link]

And people wonder why MS has near total desktop domination.

KDE's Project Silk

Posted Sep 23, 2009 11:21 UTC (Wed) by anselm (subscriber, #2796) [Link] (2 responses)

Well, maybe it's just me, but if I have to have bloat then I want that bloat to actually *work*. This is something that Akonadi so far has failed to deliver for me -- it insists on launching its MySQL server and trying to import stuff from our LDAP server, but then it basically quits and says »I'm broken, I can't do anything«. Of course once it has noticed that it is, in fact, useless it would be much too much to expect it to clean up after itself (say, by killing the MySQL server again). Incidentally, the help link on the dialog in question leads to a 404 error. I don't mind debugging stuff but if people actually seem to go actively out of their way to make it difficult then I have better things to do with my time.

I'm cool with bloat that actually delivers something worthwhile on top of what is already there. What I am less enthusiastic about is developers who appear to spend all their time pushing the envelope and don't seem to care about the day-to-day stuff. They're busy working on a car that will fly (and it actually does, in the wind channel in the lab) but the fact that the steering wheel falls off the moment the car is being driven out of the driveway into the road is below their attention threshold. (After all, flying is much more important, and the rest is just trivial stuff that the users can fix if they are »bothered«.)

I'm looking forward to the day when Kontact will actually be able to maintain a stable connection to an IMAP server that is running on the same machine, with no gratuitous hangs. This has never worked quite right as far as I am concerned -- it's OK most of the time but once or twice a day Kmail just hangs until either the IMAP server is restarted or a timeout happens. (In point of fact the IMAP server is only necessary in the first place because Kmail doesn't handle Maildirs the way it ought to, according to the author of the offlineimap utility, which doesn't appear to be a problem with other MUAs.) *Maybe* Akonadi will help there but I'm not holding my breath. I'm also looking forward to the day that the message editor in Kmail will once more handle Ctrl-K the way it is supposed to, which is apparently broken in KDE 4.x. There is more stuff in the KDE 4.x Kmail that used to work in 3.5 but no longer does -- but hey, the developers are working on an INTEGRATED FRAMEWORK so who cares about little annoyances like these? If the users are »that bothered« with them they can go and fix them themselves, because the developers are too important to worry about them. If a user dares voice an opinion that something the exalted developers have decided may not, in fact, be the greatest idea on Earth then they're »whining«. Right?

KDE's Project Silk

Posted Sep 23, 2009 14:15 UTC (Wed) by halla (subscriber, #14185) [Link] (1 responses)

Come off your high horse and get real.

Do you really think the developers think that way? They aren't in it for
gratuitous coolness, as much as it might please your ego to believe that.
Don't be ridiculous. There are people working really hard to solve real,
hard problems -- problems that didn't exist in the days when KMail was
first designed, which only surface with today's email load. It's actually
one of the things that is developed commercially, instead of by misled
volunteer enthusiasts -- there are actual customers paying for akonadi,
kontact and kolab.

It's no doubt fun to rant like this, but you're simply wrong about the
developers motivations and priorities.

KDE's Project Silk

Posted Sep 24, 2009 8:16 UTC (Thu) by anselm (subscriber, #2796) [Link]

Whatever. But I suppose that even those »paying customers« would like their Ctrl-Ks to work correctly ...

KDE's Project Silk

Posted Sep 23, 2009 0:12 UTC (Wed) by alankila (guest, #47141) [Link] (2 responses)

It'd be mostly horrible idea to have, say, facebook.com and facebook2.com and then have these sites not integrate seamlessly. The value of many of those sites is in the size of the network. Have two sites and in the worst case both are equally popular and you have just neatly halved the size of the network and thus reduced its value by even more than that.

Anyway, google wave is on the horizon and might be just what everyone wants: social network where all servers interoperate by design, data is not held as hostage on anyone's server but copies of data are passed around to every participant who needs it, anyone can start a server, etc. It could well provide the platform that everyone could live with.

Oh yeah, it's supposed to have open-source frontends and backends as well.

KDE's Project Silk

Posted Sep 24, 2009 21:29 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

Anyway, google wave is on the horizon and might be just what everyone wants: social network where all servers interoperate by design, data is not held as hostage on anyone's server but copies of data are passed around to every participant who needs it, anyone can start a server, etc. It could well provide the platform that everyone could live with.
Sounds just like USENET to me.

KDE's Project Silk

Posted Sep 28, 2009 16:23 UTC (Mon) by nye (guest, #51576) [Link]

Then you're not listening :P.

You should take a look at Google Wave - the presentation at wave.google.com is worth watching if you have the time (it's about an hour and 20 minutes).

Of course you might still not like the sound of it, but personally it's the first 'next big thing' idea I can recall seeing which doesn't seem completely pointless.

KDE's Project Silk

Posted Sep 22, 2009 11:30 UTC (Tue) by modernjazz (guest, #4185) [Link]

...and don't want their apps to become harder to use because they have all
these buttons devoted solely to features I don't use.

But I expect all this is resolvable, and that making our applications
better at sharing data across the internet will have positive impact even
for those of us who merely want to use our computers to get "real" work
done.

KDE's Project Silk

Posted Sep 22, 2009 13:54 UTC (Tue) by sebas (guest, #51660) [Link] (1 responses)

I think a Free software implementation is actually the best way to ensure
that your wishes be respected. :)

The idea is not to make the user do something, but to make the computer
support better what many people are already doing with their data (and
devices in general).

Free software is our best bet, but our attention still needed

Posted Sep 23, 2009 13:10 UTC (Wed) by coriordan (guest, #7544) [Link]

Free software is like democracy. Sometimes people elect dangerous idiots.

In free software projects, if the users don't clearly value freedom, then companies add non-free plugins, non-free dependencies, and non-free websites to the free software systems.

I have the source and the freedom, but I don't have the time to reprogram my desktop. I have to rely on the users in general signalling to the developers that anti-privacy features and non-free dependencies are not what we want. This is worlds better than the situation of a user of proprietary software user, but it does take some daily effort.

KDE's Project Silk

Posted Sep 22, 2009 11:34 UTC (Tue) by csamuel (✭ supporter ✭, #2624) [Link]

How about something like the OpenDesktop Plasmoid in KDE 4.3.x ?

http://dot.kde.org/2009/05/01/social-desktop-starts-arrive

Not played with it yet but the article does make it sound a bit like what
you're talking about..

KDE's Project Silk

Posted Sep 21, 2009 21:49 UTC (Mon) by richmoore (guest, #53133) [Link]

> I want a P2P desktop. A people to people desktop. I want all apps to be
aware of my social network and I want all communication to be serverless and
encrypted. No proprietary web service in between.

The aim here is to integrate with existing technologies. If you can design
and implement a system that allows the above then we'll be happy to
incorporate it.

We (KDE) are already taking steps in the direction you suggest as you can see
from the remote widget support that we recently added to plasma. This is
covered briefly in http://dot.kde.org/2009/09/08/third-plasma-summit-lifts-
kde-desktop-higher-grounds

KDE's Project Silk

Posted Sep 22, 2009 3:28 UTC (Tue) by pabs (subscriber, #43278) [Link] (8 responses)

I'd like to see this become a cross-desktop project at FreeDesktop.org

Definitely agree with the above comment about social desktops.

KDE's Project Silk

Posted Sep 22, 2009 11:55 UTC (Tue) by sebas (guest, #51660) [Link] (7 responses)

I actually don't see what the benefit of making Silk an FDO project would be. Maybe you can expand?

KDE's Project Silk

Posted Sep 22, 2009 13:16 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (6 responses)

The same benefit any project is FDO is supposed to have. Help more users by working with other desktop environments instead of just one.

KDE's Project Silk

Posted Sep 22, 2009 13:50 UTC (Tue) by sebas (guest, #51660) [Link] (1 responses)

You mean like X.org? Or the broken standardization process we're currently
trying to fix? No thanks...

If you look at Silk, you'd see that it's not a piece of code that can be
on FDO or not, it's a KDE-wide effort to improve on web integration in the
desktop and in application. You can think of it more as a set of loosely
connected components, plugins for applications for example, but also Qt-
that typically would belong onto Freedesktop.org. On top of that I'd not
be willing to implement these things without usign KDE infrastructure and
libraries.

If other projects want to adopt pieces of the code or interact with Silk
developers, that's fine of course. Still, I don't see any benefits from
making Silk an FDO project.

KDE's Project Silk

Posted Sep 22, 2009 13:51 UTC (Tue) by sebas (guest, #51660) [Link]

Aah. Parts of my reply got eaten!

... but also Qt-style APIs. Most of Silk is nothing that typically would
belong onto Freedesktop.org. ...

KDE's Project Silk

Posted Sep 22, 2009 13:54 UTC (Tue) by hunger (subscriber, #36242) [Link] (3 responses)

How does the usefulness of a project depend on the website that is hosting it? Frankly, FDO is just one of many websites that hosts open source projects.

Plus this seems to be highly KDE specific (using KDE technologies and Qt all over the place), so what sense is there to try to make it cross desktop?

KDE's Project Silk

Posted Sep 22, 2009 15:10 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

The website that hosts it would indicate the intentions of the project. FDO is the place to host specifications and code that would not be desktop environment specific.

The suggestion isn't merely to push KDE specific code to FDO. That would not make sense. Instead work with other desktop environments on things that can be shared. If code cannot be shared, specifications can be.

KDE's Project Silk

Posted Sep 22, 2009 20:49 UTC (Tue) by aseigo (guest, #18394) [Link] (1 responses)

When we do work on specifications, we do take them to freedesktop.org. After all, it's an organization KDE helped create and one which we continue to help improve. Recent additions include the Open Collaboration APIs for Free software online services (which does relate to Silk topically) and the Notification Items specification. The recent work on the Notification specification to finally bring that one together is another nice example, though not a brand new spec.

Silk, by contrast, is not about specifications, it's about very specific integration points (source code) between existing and future KDE applications and online content. So Silk is not something that would make any sense on freedestop.org, though others who are involved with freedesktop.org may wish to work on similar integration points in their software.

HTH clear things up a bit. :)

KDE's Project Silk

Posted Sep 24, 2009 2:59 UTC (Thu) by pabs (subscriber, #43278) [Link]

I was mainly thinking refactoring the code to split it into toolkit/desktop agnostic C libraries and the per-desktop code linking against Qt/GTK etc. The desktop-agnostic code could then live at FDO. A really good example of this is the Telepathy project.

KDE's Project Silk

Posted Sep 22, 2009 19:06 UTC (Tue) by oak (guest, #2786) [Link] (1 responses)

Shouldn't there be some mention of security also?

(At least I want anything opening ports in my machine or getting data from
outside of it to be scrutinized very carefully from the security point of
view. "And the intruder glides into your machine, smooth as silk...".)

KDE's Project Silk

Posted Sep 22, 2009 20:47 UTC (Tue) by richmoore (guest, #53133) [Link]

> At least I want anything opening ports in my machine

Nothing we've looked at so far requires opening any ports on your machine.
This is so far all about a much richer set of clients than can be provided by
a browser. I'm not aware of anything within our intended scope at this point
where providing a listening server would be useful.


Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds