KDE's Project Silk
KDE's Project Silk
Posted Sep 22, 2009 9:10 UTC (Tue) by kragil (guest, #34373)In reply to: KDE's Project Silk by coriordan
Parent article: KDE's Project Silk
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
      Posted Sep 22, 2009 10:47 UTC (Tue)
                               by ballombe (subscriber, #9523)
                              [Link] 
       
     
      Posted Sep 22, 2009 11:52 UTC (Tue)
                               by sebas (guest, #51660)
                              [Link] 
       
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) 
Obivously, we prefer and actively encourage "free" and "open" services, but there's nothing that stops people from implementing backends for "ugly" services. 
 
     
      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.
 
     
    
      Posted Sep 22, 2009 13:44 UTC (Tue)
                               by sebas (guest, #51660)
                              [Link] (8 responses)
       
During the beginning of Akonadi development, the idea was to actually use 
It seems that sqlite has improved in those areas, and work on an sqlite 
All that has nothing to do with forcing people to use certain webservices, 
 
     
    
      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.
 
     
    
      Posted Sep 22, 2009 22:15 UTC (Tue)
                               by sebas (guest, #51660)
                              [Link] 
       
Even if you only store three emails in it, it still makes sense to make 
As I said, an sqlite backend is under way. That would be the one catering 
     
      Posted Sep 23, 2009 5:33 UTC (Wed)
                               by dkite (guest, #4577)
                              [Link] 
       
Really, all this episode shows is that for serious desktop work, developers  
Derek 
     
      Posted Sep 23, 2009 10:38 UTC (Wed)
                               by segedunum (guest, #60948)
                              [Link] (4 responses)
       
     
    
      Posted Sep 23, 2009 11:02 UTC (Wed)
                               by nye (subscriber, #51576)
                              [Link] 
       
     
      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?
 
     
    
      Posted Sep 23, 2009 14:15 UTC (Wed)
                               by halla (subscriber, #14185)
                              [Link] (1 responses)
       
Do you really think the developers think that way? They aren't in it for 
It's no doubt fun to rant like this, but you're simply wrong about the 
 
 
     
    
      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 ... 
     
      Posted Sep 23, 2009 0:12 UTC (Wed)
                               by alankila (guest, #47141)
                              [Link] (2 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. 
Oh yeah, it's supposed to have open-source frontends and backends as well. 
     
    
      Posted Sep 24, 2009 21:29 UTC (Thu)
                               by nix (subscriber, #2304)
                              [Link] (1 responses)
       
     
    
      Posted Sep 28, 2009 16:23 UTC (Mon)
                               by nye (subscriber, #51576)
                              [Link] 
       
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
      
KDE's Project Silk
      
- "open": Documented interface, service is not necessarily free but has a stable, machine-readable API
- "ugly": closed and no openly documented interface
KDE's Project Silk
      KDE's Project Silk
      
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".
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.
backend is well underway. There's also work going on on a postgresql
backend, by the way.
of course.
KDE's Project Silk
      KDE's Project Silk
      
providing a common synchronization and access layer for PIM data. 
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.
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
      
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.
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.
KDE's Project Silk
      
KDE's Project Silk
      
KDE's Project Silk
      KDE's Project Silk
      
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.
developers motivations and priorities.
KDE's Project Silk
      KDE's Project Silk
      
KDE's Project Silk
      
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
      
           