I used to have a silk dress shirt. It was a rich blue color, a bit loose fitting and just great for the hot and humid semi-tropical climate of Hawaii where I was living at the time. That isn't the kind of silk this blog entry is about, however. Rather it's going to be about KDE Silk which is a project which aims to deeply integrate online content and communication into the user experience.
To quote the KDE Silk wiki page: "The goal of Project Silk is deep coupling of the web with the user experience while overcoming limitations of the browser. "Freeing the Web From the Browser", so to say. Project Silk takes the opposite direction of Google's Chrome OS, instead of making the browser the Operating System, we integrate the content and the communication deeply into the desktop and application "
I don't think we will, or even should try to, ultimately get rid of the web browser and online services can be insanely terrific for many different kinds of needs. What's unfortunate is that the online services world has (to speak in slightly broad generalities) artificially restricted itself to a world where the web browser is the only container while on the other hand non-web-browser software has traditionally watched the online services train come down the tracks with that deer-in-the-headlights look.
Nobody is winning from these non-strategies. I call them "non-strategies" because they aren't the result of someone(s) really sitting down and saying, "You know what, I think that's the best possible set of answers, all things considered." They are the result of people attacking the problem from the assumption that we only have what's directly in front of us to work from. There is very little "step outside the box" thinking and so instead we get people writing excessive amounts of code to get native assembler to run in a web browser window. Seriously?
When it comes to KDE specifically, we can do better and, in fact, we already do in some cases. Things like the KIPI Plugins used in Digikam, Gwenview, KPhotoAlbum and elsewhere that have integration with online services, Amarok's pervasive online service integration or Marble's usage of OpenStreetMap and Wikipedia are good examples. These certainly aren't going to improve the web development world's obsession with the web browser, but they will give people who use KDE software improved ways of working with the great services created by the web development world. At the very least, it will keep our software from becoming needlessly irrelevant just because web services take off. At best, it may provide a template for others to consider. Somewhere in between we manage to bring smiles to the faces of our users.
We have terrific tools at our disposal to achieve this right now: we have KIO's network features, we have Plasma which is much more service oriented than what it replaced, we have QtWebKit which let's us do all sorts of really cool XHTML/Javascript/C++ (yes, C++) mashups .. and now we have Silk which is bringing us things like site-specific-browsers and hightened online service integration.
In my opinion, KDE software needs to take advantage of the rising tide of features and capabilities available through online services (where applicable, anyways) to remain interesting and relevant in the long term. We need to consider that software is becoming increasingly social in usage for people and that things like pervasive availability of data and collaboration with others are becoming things computer users are starting to take for granted as "must have features". We also have a responsibility to the world at large to not aid in the creation of a situation where the only online services that are viable and interesting are vendor lock in traps; the Free web needs allies and it is hard to imagine a better candidate for such an ally than Free software communities like KDE.
I've actually written about all of the above in previous blog entries in the past, but I believe now that with Silk, the ever-growing trend of online services and the tools that have become available to us in the last year or so that 2010 may well be an inflection point for KDE and online service integration.
(This article is part of the "Key Quests for KDE in 2010" series)
Subscribe to:
Post Comments (Atom)
11 comments:
It would be nice if you used a label for all the "key quest 2010" articles, so we the readers could easily get a listing of them all.
One problem with Silk:
What does it actually do? Sebas explained it to me once, I didn't understand It. The website tries to explain that it can do lots of things, but I still don't understand what it actually does.
Does anyone know? :)
Regards, Mark.
> One problem with Silk:
> What does it actually do?
To me it sounds like a coordinated effort/vision to make desktop applications integrate web services.
Basically:
- have a library app developers can use (to call common services)
- have a common umbrella.
We embrace the web, instead of getting run over by it.
Some comments:
1. The techbase-page mentions Jolie, I do not think that Jolie is the best solutions to build distributed applications. There is another technology. It has very good Qt and KDE integration, simple interfaces for C++, Ruby and maybe others (don't know about Python and EcmaScript, have not tried it), it uses a fast and simple protocol and is available in every KDE-environment: DBus. SOA is just a complicated term for such simple things like RPCs. Most of us do not want to change everything to services, I do not want to use a programming-language that is only focused on proper services. DBus is a great tool, it should be easier to improve the TCP/IP support than using a new programming language. The "all services together" idea of Jolie is not too useful, because different services are handled differently, thats why it's not bad to have an API for MediaWiki and a different one for micro-blogging.
2. Although it's better than Chrome OS, we should not forget freedom but the Wiki mentions some Google services and Facebook. That's the wrong direction! There are better possibilities which are partly implemented: Integration of Wikis, OpenDesktop, Open Street Maps and Identi.ca, maybe some small services to collect some data could be implemented especially for Silk
3. Selkie should include other technologies than JavaScript+HTML, e.g. Ruby, KXmlGui and .ui from Qt. And of course it should be integrated into Konqueror.
4. It is good that you mention KIO, some features listed in the Wiki should be implemented with KIO+KParts. For example the web-gallery-browser. The most flexible and most KDEish implementation: A KIO-Slave for web-image-gallerys and a fancy KPart to display the stuff (e.g. something like Cooliris/Coverflow).
Jonathan
@Jonathan: well Jolie is already being used for remote Plasma widgets.
Actually Telepathy + Tubes + Telepathy-Salut (eg zeroconf chat) + p2p D-Bus would be a pretty good solution (you don't want to export a whole bus over tcp/ip for security reason) for doing RPC calls over the local network. Telepathy-gabble could be used for RPC with your jabber friends over the internet.
P2P D-Bus would require rewriting half of QtDbus since QtDbus code makes this crazy assumption that there's always a bus for the d-bus. ;) So its not trivial either.
Anyways I don't know much about Jolie, but it seems like a fine solution for RPC. Jolie could also be exported over Telepathy-gabble and telepathy-salut via stream tubes (though the latter isn't needed likely since it already does zeroconf, but sharing plasmoids with your jabber buddies could be cool).
@Mark Kretschmann: Diederik pretty much nailed it; rather than a specific, single software product, Silk is a strategy to get more web technologies mated with our own (and vice versa).
Silk does have some concrete products: Selkie, some libraries ... but it's in the application of those tools in KDE software that matters.
in that sense, it's a bit more like Solid or Nepomuk, though not quite so purely a framework (though it aims to provide some frameworks).
personally, I don't think it will touch Amarok very much since you guys already have this well figured out. the rest of the KDE family sort of needs to catch up ;)
and yes, there is also new tools needed, like Selkie.
Jolie:
I had a look at the Plasma-sources: They seem to use QtJolie without any Java-stuff, without interpretation of Jolie etc. Is that right? It seems just to be nice: Services using Qt's events and a special protocol.
Jonathan
I think this is a very good direction for KDE to take. It seems that currently, the only online content that is seen in native applications is RSS/ATOM and IMAP/POP, as well as some incredibly specific APIs. There's so much room for improvement, in my opinion the really interesting ones are:
RDF: There are large semantic databases out there in RDF, but the only useful way to get this information is through some Web interface they may offer. Having Nepomuk spreading its branches throughout the desktop looks like a great way to overcome this: offer semantic data in those places where it is most useful (Marble, KMail, whatever), regardless of whether it's come from a local source or online, and filtered from various sources to offer everything of relevance, not just the contents of one specific data repository.
XMPP: Usage of XMPP (Jabber) for "instant" messaging is a massive area for potential coolness. As an example of its under utilisation, the microblogging plasmoid polls Identi.ca at set intervals for updates, when Identi.ca can send those through XMPP as and when they arrive instead. Having applications talk to each other over XMPP is something that excites me, for instance Telepathy Tubes, which allows serialisation of anything into text, sending it over XMPP then reconstructing it on the other end (I've seen demos for DBus, remote desktop and multiplayer games). I started writing a generic library for XMPP Publish-Subscribe a while back athttp://github.com/Warbo/pubsubclient , and would happily bring it back to life if needed (shameless plug I know ;)
CouchDB: This is very interesting from a p2p point of view, since it is pretty straightforward to make collaborative multi-user applications (like social networks) in a way that's decentralised and under every users' control. There is some overlap here with Nepomuk as far as KDE is concerned, but it's definitely worthy of consideration for things like a networked Basket or sharing info about places in Marble (like Google Earth has, but without the one-server-to-rule-them-all-and-in-the-proprietaryness-bind-them).
FUSE: I think there's an under-appreciation of FUSE's flexibility in getting data to applications. Implementing a service in a program is great, for example Jamendo's integration in Amarok, but there's something UNIXy in me that makes me think, if there were a Jamendo FUSE filesystem then every music player could read it. This is just a throwaway example of course, but FUSE is definitely an option when bringing online content to native applications (although one that needs lots of GUI-friendly frontend love ;)
As a final point, I think that if online stuff reaches the point of significantly enhancing the user experience then it would be perfectly acceptable to include online account setup when beginning with KDE, for example "KDE likes company, click here to create an online messaging account to connect with friends or here if you already have one you'd like to use" (with XMPP being default of course!).
I should stop braindumping now, great post + comments :)
I think there was a KIO-Fuse-bridge...
I think complete abstraction of local or remote data is the first step to take, as someone pointed out already. When designing application, when it comes to data, make sure to keep that in mind and consider it might take some time to fetch it all.
And why should i have 'file->open' and 'file->open location'?
Then for some ideas, opera might be worth the look. Historically, theirs innovations were often followed by mainstream. Recently, they released 'unite', which is like a web server with applications, like a media player everyone can add songs to the playlist and listen at the same music the same time. I like that idea :)
But I don't feel compfortable with what the future, i fear, will come to. I think we might end up with a kdm loggin in synched with a server, and the local session synched up with the remote one.
Then we will add kde friends, someone will release a 'take-the-quizz' plasmoid and guess what...
@Warbo: I don't think Fuse is very well suited to slow network applications, because you really need more feedback when you're doing network operations. It requires some UI to get right. For instance when using sshfs and it loses connectivity it results in hanging applications, even `ls` hangs, it just doesn't seem very practical.
Of course I agree with you about Telepathy. It should be the "real-time communication" solution of Silk.
Post a Comment