QT "Remoting" and D-Bus questions

[QPlace]

I am looking for a library, preferably open-source and currently in usage, that provides functionality resembling .NET remoting. I know about Corba existence (I never programmed against it and it does not look easier to program and config comparing, say, DCOM), but I suspect that features resembling “.NET remoting” were implemented in C++ outside of Corba.
If you are aware about such tools/technologies I will appreciate it if you can point me to them.

The closest technology that I found supported by QT is "D-Bus". From what I understood it is currently available on unix/linux OSes only. The questions are:
1. Is it indeed оnly supports unix? (at least that's what qt4.4 preview docs tell). Do you know of QT plans to support it on windows?
2. The information about D-bus outside of QT docs is very well hidden. Searches for D-bus, QTDBus, QDBus produce very little information. It will be great if you can point me to QTBus discussion forums, information about usage etc.
3. Port of DBus to windows (windbus) looks to be dead. There are only 4 entries in sourceforge forum. Any comments on may be other windows projects with DBus that are aliive?

Thanks.

[Thomas]

1. Yes. There is very high probability that D-BUS will never be ported to Windows. Though, you could give it a try with Cygwin.
2. First hits on Google "revealed" dbus.freedesktop.org/doc/dbus-tutorial.html. ;)
3. Yes, it looks rather outdated but it is the only semi-official port.

Let me ask a question: what excatly do you want to accomplish? Remote Procedure Calls, platform independent data exchange and use of applications over a network?

[QPlace]

1. Yes. There is very high probability that D-BUS will never be ported to Windows.
Can you share your understanding of the reasons behind that decision?
2. First hits on Google "revealed" dbus.freedesktop.org/doc/dbus-tutorial.html. ;)
I re-read my post and realized that I did not express myself clear enough. I knew about DBus "standard" info, such as one you referred me to. What I don't understand is that apparently QT took and probably extended this technology and now calls it QDBus and distributes it as QT offering. I was surprised to not find plenty of information from QT about such non-trivial technology and also absence of questions/discussions etc.

Let me ask a question: what excatly do you want to accomplish? Remote Procedure Calls, platform independent data exchange and use of applications over a network?
Well, bottom line is that .NET remoting allows very easy development of services talking to each other accross process or machine boundaries. I am not saying that it is a silver bullet in every case, but in "good enough" scenarios it works well and allows quick development without looking in the plumbing. I know how I can roll my own implementation of such functionality in C++; I did similar things in the past and that's precisely what I am trying to avoid doing. I am not a system developer and never wanted to be one, I am more interested in correct system architecture and business processess than in the details of how Nagle alorighm should work or how to instantiate or use named pipes or HTTP for serializing/deserializing data packets. I am quite sure that kind of a weel is being reinvented every week or so. Give me the service to use, that's what I want :). For example, here is one framework for Delphi http://www.delphi-online.at/projects/ddobjects/index.php. Although one can use it for CBuilder I will be delighted to find C++ version for such functionality. Again, .NET remoting is a very good example of what I am trying to accomplish in C++ in order to use it with QT

[Thomas]

The reasons are simply. Windows does not provide the same architectural layers which unixoid OSes provide. It is "not that easy" to implement the same functionality on different platforms without an abstraction layer.

QtDBus simply provides a C++ interface to D-Bus.

All right. Since the .NET world is as remote for me as Samoa is (no offense, Samoans), let's compare D-Bus to CORBA. D-Bus is slim, looks nice, cannot do all of what CORBA can, does not provide Serivices (in the sense of CORBA). It is kind of a high level protocol to make applications talk to each other, execute (remote) methods, return values. That's it.

E.g. D-Bus does not have such a thing like streaming services which come with the TAO ORB services (orbsvc) automagically (if enabled). One has to implement this kind of stuff. CORBA is more a top down implementation. Heavy stuff covering every case, billions of languages- well four at least: C++, Java, Python, C (crooked thoug). D-BUS is more bottom to top: What do we need, how do we do it in an intelligent and slimline way. I would call it low profile.

If you nedd applications calling remote methods, have some signalling plus return values, give D-Bus definitively a shot. If you need more, well, better use a heavy weight.