To read all comments associated with this story, please click here.
Depends on what you are trying to achieve. It looks like part of the goal of this is to enable integration without linking period, which would be required if an application wanted to integrate without taking on the licensing responsibilities that linking against gpl libraries incurs.
sounds a bit like they are back to the unix idea of pipes but rather then setting them up on a case to case basis its happening in the background while the users just see the gui.
kinda like having a commandline tool and then a gui that basicly trows input at the tool and parse the output.
rather then having special interfaces buildt into the lib you trow a sequence of code flanked by xml at the lib's input pipe. basicly the lib have one input and one output rather then 100+ like they can have today.
there may be some "wasted" cpu as the lib have to prosess the packages of data before doing anything with them.
i must say that it reminds me of tcp/ip on a ipc level 
One of the major points is language independence -- you're getting rid of a language based API.
Not only that you're entirely decoupled the implementation portion, so you can handle those messages however you want, this goes beyond idiomatic expressions of languages.
This also allows for ease in multiplexing resources.
The benefits are plenty and as for performance that's going to be dominated by the service, more than anything. This doesn't seem like a fine granuality system.




Member since:
2005-07-06
You're going to need to call some function or other, which means you need to define some API even if that is carried across a protocol. KDE is slow enough as it is. You could achieve the same damn thing by linking to different stub libraries that call the changing real API. Either way this isn't free: you need to keep the "XML schema"/protocol or stub library or whatever up to date, and you incur run-time overhead for what I would argue very little gain.