Linked by Thom Holwerda on Sun 4th Sep 2005 10:15 UTC, submitted by Lumbergh
KDE "RuDI is an architectural approach whose goal is to achieve loose coupling among interacting software components instead of linking to libraries. A service is a unit of work of the desktop done by a service provider to achieve desired end results for a 3rd party service consumer. How does RuDI achieve loose coupling among interacting software agents? It does so by employing two architectural constraints: An extensible XML schema allows new versions of services to be introduced without breaking existing services. Second we send messages over a protocol instead of calling explicit individual member functions."
Thread beginning with comment 27198
To read all comments associated with this story, please click here.
Bad Idea
by Luke McCarthy on Sun 4th Sep 2005 11:33 UTC
Luke McCarthy
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.

Reply Score: 1

RE: Bad Idea
by yokem55 on Sun 4th Sep 2005 11:56 in reply to "Bad Idea"
yokem55 Member since:
2005-07-06

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.

Reply Parent Score: 5

RE[2]: Bad Idea
by hobgoblin on Sun 4th Sep 2005 15:15 in reply to "RE: Bad Idea"
hobgoblin Member since:
2005-07-06

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 ;)

Reply Parent Score: 1

RE: Bad Idea
by Saem on Sun 4th Sep 2005 21:06 in reply to "Bad Idea"
Saem Member since:
2005-07-06

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.

Reply Parent Score: 2