Re: [g-a-devel] AT-SPI questions

[Bill Haneman <Bill Haneman Sun COM>]

Hi Everyone:

I'll try to reply in some detail to Olaf's questions when I return from
my holidays.  Thanks Olaf for taking the time to enumerate them.

For the moment, I'll just mention, regarding the issue of LSB, that as I
understand the proposals regarding AT-SPI and the existing
implementation, there should be no corresponding "cementation"
long-term.  Also, I don't think the current FSG proposal would enshrine
any libbonobo dependencies.  The libbonobo dependency of the current
at-spi implementation library is only an implementation detail; in fact
I do not believe that it would be appropriate to pull libspi.so into the
ABI suite at all.

So: first, the "many worlds" approach provides a path for eventual
solutions which use non-CORBA transport.  Personally I think an IDL
compiler or at least a similar degree of 'automation' with regard to how
the IDL is mapped to ABI would be a reasonable requirement for an
alternative to be blessed.

Secondly, I don't think that library dependencies should come into the
LSB equation.  I think that even for the current at-spi "world", only
the client bindings and skeletons (defined by applying the OMG
specification to the IDL) should be part of a conformance test.  I
certainly agree with you that making libbonobo part of the LSB
conformance test doesn't seem like a good idea, rest assured that I have
no desire to see that happen.

More later,  best regards,

Bill

On Fri, 2006-08-04 at 18:11, Olaf Jan Schmidt wrote:
> Hi!
> 
> I am probably still misunderstanding some things, so I am summarising what I 
> have understood so far of the whole AT-SPI picture. This email functions both 
> as an attempt to find possible misunderstandings, and as an explanation why 
> it is important for KDE to move AT-SPI onto D-Bus. Please correct all wrong 
> assumptions, and keep in mind that I have no power to tell Trolltech what to 
> do with AT-SPI.
> 
> Imaging a new, much improved version of kmousetool talking to KOffice on a KDE 
> desktop on FreeBSD or IBM AIX.
> 
> The GNOME accessibility team suggests to implement AT-SPI support in Qt by 
> linking to ATK. This requires significant changes in glib and/or ORBit2, and 
> significant effort for the Qt-ATK bridge. It would also only deal with the 
> application side. Doing a move to D-Bus later would be the same amount of 
> work as doing it now, meaning that going for D-Bus directly takes 
> significantly fewer resources altogether.
> 
> GNOME applications read a gconf key to check whether AT-SPI is enabled. Do 
> they also watch changes of the gconf keys during runtime in case the setting 
> gets changed? And what do non-GNOME applications do instead?
> 
> The assistive technologies use Bonobo-activation to start the AT-SPI registry. 
> Does this mean either linking to libbonobo or reimplementing it with a 
> different ORB?
> 
> There is no complete C++ ORB that runs on all platform KDE targets, which 
> means we have five options:
> 1. Abandon all plans that we have for assistive technologies.
> 2. Put a lot of work into a solution that works on only some of our target 
> platforms.
> 3. Make KDE applications support both Bonobo-AT-SPI and D-Bus-AT-SPI. This 
> would mean doing twice the work for only half a solution, because GNOME 
> applications would still fail to work with KDE-based assistive technologies.
> 4. Write an incompatible version of AT-SPI.
> 5. Convince GNOME to join us in our move to D-Bus, which means work on the 
> framework now, but significantly fewer work for the authors of KDE-based ATs 
> later.
> 
> The GNOME accessibility team suggests to make the CORBA- and Bonobo-based 
> version of AT-SPI a part of the LSB standard, which also means standardising 
> all dependencies of the AT-SPI registry. Which exactly are these?
> 
> The LSB requires interfaces to be around for at least 6 years, which means 
> that a D-Bus-based version of AT-SPI would be non-standard until at least 
> 2013.
> 
> ORBit2 is described by Michael Meeks as not sufficiently documented, virtually 
> unmaintained and only a "subset" of the OMG specification. Which role does 
> Michael Meeks have among the ORBit2 developers?
> 
> I once suggested to reduce the number of dependencies the AT-SPI registry has, 
> and Bill Haneman answered that this doesn't make sense since our long-term 
> goal is D-Bus anyway. Or did I misunderstand him?
> 
> Bill also say that a D-Bus-based variant of AT-SPI is not a real AT-SPI. How 
> does this fit to the agreed "many worlds" approach? Or did he only mean that 
> we should use an IDL compiler for themove to D-Bus?
> 
> I know that the GNOME team has spent a lot of time for discussing 
> interoperability with KDE, and I truly thankful for that. I also appreciate 
> the offer for constructive discussion of the obstacles towards AT-SPI use in 
> Qt and KDE.
> 
> And please don't see our push for a D-Bus-based as an attempt to create 
> incompatibilities. Quite the contrary - it is a compliment that we plan to 
> make the excellent work of the GNOME accessibility team useful for us.
> 
> Summary: My fear is that implementing the AT-SPI support in Qt via ATK 
> initially will make it impossible to prevent LSB cementation of 
> Bonobo-AT-SPI, which would totally evaporate the goodwill towards AT-SPI that 
> we have build within the KDE community. Making the decision to go directly 
> for D-Bus is certainly not popular with everyone, but it might be the wisest 
> course in a long-term perspective.
> 
> Olaf
> 
> -- 
> Olaf Jan Schmidt, KDE Accessibility co-maintainer, open standards 
> accessibility networker, Protestant theology student and webmaster of 
> http://accessibility.kde.org/ and http://www.amen-online.de/
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel