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."
Order by: Score:
applescript
by grrr on Sun 4th Sep 2005 11:33 UTC
grrr
Member since:
2005-09-03

it reminds me of applescript, not the language but the mechanism. Apple script does not use xml but also a tree like structure and it does also send messages. Am i correct? and how does it compare?

Reply Score: 1

RE: applescript
by plfiorini on Sun 4th Sep 2005 21:09 UTC in reply to "applescript"
plfiorini Member since:
2005-06-30

AppleScripts seems more like DCOP.

Reply Score: 1

RE[2]: applescript
by grrr on Sun 4th Sep 2005 21:43 UTC in reply to "RE: applescript"
grrr Member since:
2005-09-03

but applescript sends messages (apple events) more like rudi as i read in the paragraph "RuDI Defined and Explained". there they also compare rudi to dcop so maybe rudi is more like apple events then like dcop

Reply Score: 1

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 UTC 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 Score: 5

RE[2]: Bad Idea
by hobgoblin on Sun 4th Sep 2005 15:15 UTC 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 Score: 1

RE: Bad Idea
by Saem on Sun 4th Sep 2005 21:06 UTC 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 Score: 2

Web services?
by Anonymous on Sun 4th Sep 2005 16:32 UTC
Anonymous
Member since:
---

So, web services running on localhost instead of over the network then? Sounds like a really good idea and can also allow for a nice open web services/thin client infrastructure in the future. Application Service Provision as it should be done!

Reply Score: 1

This isn't dbus because...?
by Phil on Sun 4th Sep 2005 16:42 UTC
Phil
Member since:
2005-07-06

Surely the two main DEs don't need to be implementing 3 different IPC systems between them?

Reply Score: 1

RE: This isn't dbus because...?
by Anonymous on Sun 4th Sep 2005 17:05 UTC in reply to "This isn't dbus because...?"
Anonymous Member since:
---

RTFA. D-Bus is said to be 'natural choice' for underlying IPC system.

Reply Score: 2

Similar to COM
by Anonymous on Sun 4th Sep 2005 18:41 UTC
Anonymous
Member since:
---

In theory this is similar to MS's Component Object Model (COM). The difference seems to be that it is not a type independant communication framework like COM, but rather a true protocol based system.

Reply Score: 0

Not good
by Anonymous on Sun 4th Sep 2005 21:17 UTC
Anonymous
Member since:
---

Look, DCOP is well designed. That's why it has stayed with KDE all this time. D-BUS is equally well designed and with its lack of dependencies could establish a Linux wide standard of inter-app communication.

But this is not well designed. When almost everybody is crying that today's desktop software is too bloated and loads too slowly, you certainly don't want your inter-desktop communication to include XML processing!

The basic idea is sound, but the protocol should be made much more simple. Do one thing well. I bet an extendable protocol (as in HTTP-like, not HTML-like) for D-BUS would do the job admirably.

Reply Score: 2

Bloat is a word used by the clueless
by Saem on Mon 5th Sep 2005 02:25 UTC in reply to "Not good"
Saem Member since:
2005-07-06

This is by no means an IPC replacement, it's merely an option, this doesn't mean that DCOP won't exist, but DCOP is better for finer grained IPC, hence why it's so big for scripting.

RuDI is meant to scale BEYOND KDE, that is to say the desktop service could be any desktop service, rather than having all these services syncronize against various standards and so on, don't forget ABI and version compatability issues you simply have them work together with RuDI, BTW, this goes well beyond Linux. KDE runs on many platforms. Heck, there are intentions to expand on to windows with Qt4.

Reply Score: 4

RE: Not good
by Anonymous on Tue 6th Sep 2005 16:46 UTC in reply to "Not good"
Anonymous Member since:
---

How about using BEEP + XML instead of HTTP + XML ? That way there maybe less overhead.

Reply Score: 0

Desktop Kernel?
by Anonymous on Mon 5th Sep 2005 08:44 UTC
Anonymous
Member since:
---

Sounds like a desktop kernel to me.

Where's that fellow who was complaining about "kernel" being used outside of OS contexts?

This is exactly the same thing, a central software kernel that locates and provides services, and routes requests to those services. All loosely bound.

See OSGi and Eclipse for another example of a software kernel/plugin architecture.

If you have two different environments, with particular idealogies and styles, then to integrate the two you need a system that is bigger/more abstract than both of them. I think Knuth might have said somthing about that.

Reply Score: 0