Thomas Zander wrote: > Mostly because Uno is not supported as much as dbus. dbus is an open > technology and supported by multiple vendors on a lot of platforms. > Uno is an OpenOffice only library that debian for example does not ship > separately. (I think people would not thank me if KOffice came to depend on > openoffice as an installation target ;) > Also, its overkill for just a communications-layer.
You seem to overlook that UNO and OOo are two different products as I wrote in the mail you just replied to. You don't need OOo to use UNO. And the UNO runtime is comparably small, only a few MB. I wouldn't call that overkill. I didn't start this discussion, I just felt that mentioning dbus in the context of the Zotero interfaces completely misses the point. And as you forgot to mention the missing Windows support I felt the need to point this out as otherwise the uninitiated reader could get the wrong impression. Having "multiple vendor" support already for dbus doesn't help if a specific problem needs features that dbus doesn't offer. So we should leave this discussion out for the moment and wait until other vendors show up. Zotero seems to work pretty well with SOAP (see below). > I think you are assuming too much negative on the side of dbus. At least you > are making dbus sound bad based on what looks like preference of a home grown > solution. No, I just pointed out that dbus has some weak spots. It surely has its merits where it is already used, no doubt. But if you need Windows support today it is a no-go. Time will show how much time it will take to reach a considerable maturity of dbus running on Windows. > Specifically, I doubt the maturity and versatility parts of your statement. > This is not a product that is written by some newbees. Its based on many > years (10+) of experience of both the gnome and kde groups that have had > several implementations over the years, of which this is a rewrite which is > already some 4 years in the making (well, mostly designing, the coding came > more recently) If I was talking about maturity of course I didn't mean the developers, I talked about the products. Sorry if it sounded differently. It was not my intention to talk bad about other developers I even don't know at all. I think UNO is more mature than dbus just because it exists as a real product for a longer time. It's simple math to verify this. UNO has much more years running on several platforms, supporting in - and out of process calls and working with remote clients. > I don't know performance wise; but without actual testing I think neither of > us should make any assumptions. :) I know that a not so small software vendor searching for an RPC technology did comprehensive and in-depth performance tests and UNO outperformed all others tested so they are using UNO now (the URE to be more precise). Admittedly I don't know if they tested dbus also. But if dbus is so widely adopted as you described I would wonder if they didn't. I will try to find this out. > I just hope you will step over the one-sided view you have and see that a > *lot* of software is moving to sharing that 1 IPC layer. Not just desktop > software, but also systems like HAL etc. No doubt, dbus has found its place. But it's not the first choice when you are looking for an RPC system that runs on Linux *and* Windows and is able to interface remote applications e.g. using SOAP. Do you agree with that? >> Perhaps a bridge between dbus and UNO would be a good idea? > > That would certainly be a good idea. I don't know uno too well, but I think > its aiming for a much broader technological solution set. Adding dcop to the > mix will allow a lot of opportunities in both directions. Yes. We already have bridges to .NET, Mono and COM, we even have a nearly complete bridge to XPCOM, adding dcop would be a fine addition to our "friends". Would be a topic for [email protected] though. > If you are serious about providing one API for apps like zotero that a range > of applications can implement, then I do think that reusing an existing and > accepted IPC layer is the way to go. Sticking to uno doesn't help apps like > zotero to program to that API as it would end up being OOo only anyway. So > that misses the mark. Currently we are talking about Zotero. They are using SOAP and this is fine for both MSOffice and OOo as well. And I don't see a reason that KOffice can't use it that way. So I would go for it. SOAP is absolutely adequate for the task, it should be usable from all decent RPC layers and is platform independent. What else do we need? My suggestion to "translate" the SOAP API into something more general was only an idea how we could extend this into something even more widely usable in OOo. If you read this again carefully you will recognize that I talked about "driver" objects that OOo can use to interface with other bibliographic sources. If that was something using dbus it wouldn't be out of my picture. Just a technical challenge. :-) > ps. In case you didn't notice yet, I'm not on the dev list. So if you can cc > any replies. That would be great. Done. My filter that marks moderated postings was inactive so I missed that. Hmpf. 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]
