Thomas Zander wrote: > The dbus port on other platforms actually works pretty well and is being > actively developed with a very clear goal in mind by various core-KDE people. > To make dbus be a true cross-platform solution. > I'm not upto-date on the latest development, but if its not yet there, I'm > confident it will be soon.
Hm, I had a look on the Windows port and to me it looks very quiet: http://sourceforge.net/project/stats/detail.php?group_id=171968&ugn=windbus&type=svn I'm afraid the it could be something like the legendary Windows version of Evolution that still fails to be usable. But maybe I misunderstood the statistic pages or it's just a temporary inactivity (though the project started just last july). > In other words; dbus is the newest technology on the block that is also the > first that is fully open and interoperable. And, most important, in active > development. Well, perhaps not here but perhaps somewhere else we should discuss why you think that dbus better suits the needs of an application that e.g. runs on Linux, Mac and Windows than UNO does. UNO already now works great also on Windows and some Unix versions. On Windows it is interoperable with .NET and (in a limited way) COM. On Windows it is also perfectly integrated into all scripting languages like e.g. VB, VBScript, JScript and the Windows Scripting Host. It also has language support for the most important professional programming languages C++ and Java and also Python and some other scripting languages on all supported platforms. In case you didn't know: UNO is available as a standalone package called URE. There is already basic support (and growing!) in Eclipse and NetBeans for the development of UNO components with the URE. So you can use it independently from OOo. Porting UNO to other platforms is comparably easy, especially if the platform has a GCC (and which one hasn't?). Even the remote protocol of UNO is just a UNO service itself and so can be exchanged. And AFAIK the remote machine support of dbus is not fully done while the code doing this in UNO is mature and fast. UNO has a history of nearly 10 years of development and is a product since roughly 8 years. It already has proven to handle remote communication through the internet as well as locally, both in production environment. The additional support for in-process calls in a transparent way also comes in very handy. Distributing components both in-process and out-of-process and handle them tranparently gives a great flexibility to the developer. So overall I think that dbus surely is an interesting technology but it must take some more years to catch up with UNO in terms of maturity, versatility and performance. But as I said, perhaps we should discuss this elsewhere. I just thought that your (understandably ;-)) one-sided statement about dbus and especially it's missing pieces could give uninitiated people a wrong impression. So I wanted to add *my* one-sided statement about UNO to destroy this impression and leave them at a loss thinking about what would be better. :-) Perhaps a bridge between dbus and UNO would be a good idea? Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
