The KIO framework has been with KDE since eternity, in some parts long before KDE 2 came out if I'm reading the meta information correctly. It provides us with many useful slaves, including one for HTTP and WebDAV. However, despite the hours of work which went into it, and despite the fact that it works very well for most of the time, we can do better. The software world beyond the desktop is making its functionality increasingly available through well-defined interfaces. We, on the other hand, need a good API to make the ubiquity of services a reality. If we provide one, more developers will consider our libraries as a good choice for their applications.
As one of these developers, the difficulty to access services with a REST interface has annoyed me for quite some time. At first I've thought that the mistake must be with me or my source code, but now that patches to KIO are available I know that it was simply impossible before. Now it is finally possible.
(To be fair, SOAP users had a similar issue in early KDE 4 times. And with the new KXMLRPC library, operation-centric web services seem to have a good standing with KDE, too.)
Back to the topic. How much functionality should such a framework contain? Everybody wants it to be as light-weight as possible, and I agree. Still I'd like to see some additional functionality over the state transfer handling it does right now. Its techbase page already mentions a resource cache and a transfer cache. The transfer cache will avoid forcing the application developer to handle network connection trouble. If a transfer fails due to a server being down or the laptop's ethernet cable being loose, why should the developer have to care? Robustness by automatic failure handling is therefore worth the additional couple hundreds lines of code in any case. The resource cache, on the other hand, will be more or less duplicating the kio_http cache, but on the other hand might give the developer more control about the amount and strategy of caching. Unfortunately there's no generic caching layer in KDE yet which we could simply use at this point even though many other libraries like KNewStuff or KGGZ could profit from such a layer. If access to services becomes ubiquitous, then caching will as well.
Other than these two extensions to Lokarest, I can't think of any which I'd need in any or at least most applications using this framework. But there might be others hidden more deeply. Interestingly, Sun recently released a reference API for accessing REST services through their JCP, but beware that its licence is inherently non-free and tried to prevent alternative implementations. If that's not the intention and just the wording, the company should get better lawyers who can bring their point across more clearly. If it is indeed the intention, then good riddance JCP and welcome free, unencumbered alternatives from KDE's playground area.
fup2 kde-services-devel