Submitted by “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.”
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?
AppleScripts seems more like DCOP.
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
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.
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.
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!
Surely the two main DEs don’t need to be implementing 3 different IPC systems between them?
RTFA. D-Bus is said to be ‘natural choice’ for underlying IPC system.
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.
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.
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.
How about using BEEP + XML instead of HTTP + XML ? That way there maybe less overhead.
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.