Hi,

> 
> Havoc, these discussion aren't coming out of 'wouldn't it be fun to add
> lots of stuff to dbus?' its out of 'here's an existing technology based
> on a component technology, how can we use dbus for this case?'
> 

Don't misunderstand, I think a number of these improvements are useful. 
The work item page (MigrationBreakdown) looks sensible.

However, I think you sum up one problem pretty well here - AT-SPI is 
based on a component technology, and dbus is _not_ a component 
technology, nor was it intended to be. (There's some stuff on this in 
the FAQ.)

The intent with dbus is that you use some language's object system, or 
some other component technology, to define your API. Then dbus is used 
to _remote_ an API defined elsewhere.

This sounds like pedantic semantics, maybe it is, but I think it helps 
understand where dbus is coming from.

> Note that performance is really an issue here, have a look at the
> current profiling breakdown of AT-SPI as it stands today:
> 
> http://live.gnome.org/GAP/AtSpiDbusInvestigation/

I agree it's an issue for AT-SPI, what I'm saying though is that I doubt 
you can get dbus as fast as ORBit, without changing how the IPC is being 
used, e.g. reducing the number of calls.

Don't get me wrong - I am very happy to see dbus optimization work go 
on. I just don't want people to have overly high expectations.

There's been a sort of myth that dbus is "smaller and faster" than CORBA 
and that's why it was developed. This was never true, nor was it ever 
the intent. Well, I think dbus _is_ smaller and faster in certain 
scenarios; it makes async / nonblocking scenarios easier, for example, 
imo. But, it is definitely not faster for blocking round trip method 
calls. And in fact with the bus daemon, it is _inherently_ at least 
twice as slow... that was known from day 1.

>> Let's remember that DCOP was implemented in a very short period of time,
>> and was dead simple - MUCH less complex than dbus is - and people used
>> it heavily and successfully for lots of real functionality.
> 

The point here is that dcop could pretty much be made to work for a wide 
range of scenarios, despite 1/10 the complexity of something like 
ORBit/Bonobo. DCOP was clunkier 5% of the time, sure, but saved 90% of 
complexity. http://log.ometer.com/2007-07.html#18 is a related post.

This is the hardest tradeoff to judge in software engineering, imo, so I 
don't pretend to have all the answers and I'm frequently unhappy with 
decisions I make. I would just say, trying to make the last 5% elegant 
can, in my experience, lead to increases in complexity that ultimately 
are not worth it.

There probably isn't a good reason to debate this generality, though ;-) 
I don't think we disagree on most of the specifics here.

Havoc

_______________________________________________
dbus mailing list
dbus@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dbus