djcb: you’re falling into the same pit as Bonobo did, falling into pit created by CORBA. Bonobo & CORBA are both dead in the water, they seem like oh-so-good idea, but in the end it’s tar-pit. They both make the same basic mistake: doing everything and trying to be the be-all-end-all. We have that saying, “if somethings universal, it’s useless", although it sounds way better in Polish :).
Take CORBA for example – what exactly is that beast? IPC? But then, it’s awfully complicated, it has uber-generic GIOP protocol, which is then concretized into still needlessly generic IIOP, only over which CORBA IPC happens. Too bad that (to my knowledge) noone really implements full GIOP or IIOP, so you’re left with common enough subset instead.
So maybe CORBA is type system? Then, it’s very cumbersome (requires really high level language to hide all the complexities of it) to use, drags in useless IPC cruft and is incomplete – earlier versions (before 2.2 I think) had no standard way of implementing CORBA objects – what was there, BOA (Basic Object Adapter) was drag to use, and it lacked some crucial features, making it impossible to use without vendor extensions. Farewell portability. After BOA, there was POA (Portable OA) which replaced nightmare with hell. POA is prime example of premature optimization in action, so much that I suspect it’s really called after Prematurely Optimized Atrocity. POA trees? POA managers? POA managers factories? Activation policies? Lifetime cycle policies? Servants? Servant managers? Activation adapters? Please!
In that case, maybe it’s component system? Nah, it lacks features for that, was only equipped with additional components specification in 3.0 (434 pages, together with latest CORBA spec it’s blazing 1586 pages!), its type system is lacking and extremely cumbersome as shown above, making any attempt to use CORBA for DSO-implemented hell on Earth. Do you think implementing component would be simple matter of creating object of given (sub)class? Hah, not with CORBA, and certainly not in language like C.
Bonobo is similar – it does components, UI merging, compound documents and monikers, what have you. And all that is so complex it’s not even funny, and still doesn’t work properly. Do you think it’s coincidence everyone’s running for their lives away from Bonobo? That people throw parties to celebrate removing Bonobo code from their apps? If technology requires two layers of sugar to be barely usable, you shouldn’t be wondering if might be too complex, you should be busy making sure you’re nowhere near it.
Now, to the point – goal of DBUS isn’t to replace Bonobo. DBUS aims to be good, simple way to do IPC. Not component model, not compound document system, not $any_random_hip_idea_of_previous_20_years. It’s about Unix philosophy – do one thing, and do it well. If you need more things done, create more things doing one thing well and tie them together.