ATSPI over D-Bus (was Re: [Accessibility] Re: [Accessibility-atspi] D-Bus AT-SPI - The way forward)

[Rob Taylor]

Havoc Pennington wrote:
> 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.

good :)

> 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.

Well, yes I do understand the original idea. The problem here is either you:

a) define your interface in some language, in which case its hard for
that API to be accesses from other languages unless the interface uses
very simple types and interfaces. Hence many current dbus interfaces are
very simple. This isn't necessarily a bad thing, but is limiting.

or b) define in some cross-language component-technology-like medium.
The problem here is this doesn't actually exist for D-Bus.

The closest we have for b) in the D-Bus world seems to be the work done
by the Telepathy project. I think this kind of cross-language interface
definition layer above dbus is probably worth doing (yeah, and we have
talked about doing this before :)).

>> 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.

*nod*

>>> 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.

Yeah, I completely agree, its worth checking ourselves that we don't
complicate the simple case.

Thanks,
Rob

> Havoc
> 
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus


-- 
Rob Taylor, Codethink Ltd. -  http://codethink.co.uk