[Accessibility] LSB nature and inclusion criteria

Olaf Schmidt ojschmidt at kde.org
Fri Nov 10 06:41:24 PST 2006


I decided that I will attend the LSB meeting in Berlin on the second and third 
day (Tuesday and Wednesday).

To make this as productive as possible, I need good answers to all of the 
following questions. I am sure they will eventually be asked.

1. What exactly is the reason behind requesting AT-SPI as part of the LSB?
Why is it not enough to publish the IDL and testcases separately (apart from 
political considerations, which we might be able to address differently)?

2. LSB-conformant applications are not allowed to use any non-standardised 
interfaces at all. Bill has suggested to exclude the activation code and some 
other areas of AT-SPI from the standard. Can assistive technologies be 
written that only use the standardised parts of AT-SPI (and no activation 
code)? Are they guaranteed to work on all distributions then?

3. The LSB is a trailing standard. It is not a tool to push new technology 
into distributions, but aims to document existing agreement between 
distributions. This means that the reference implementation released by the 
LSB needs to be compatible with all complying distributions. Is it already 
clear when the latest AT-SPI implementation with reduced dependencies will be 
present in all major distributions?

4. The LSB in an ABI standard, and the phone conference made it clear that 
this is not going to change. We decided to release AT-SPI as an IDL standard 
without normative ABI. How can we reconcile this conflict without 
discouraging distributors from contributing to a new D-Bus-based ABI?
(See my other email.)

5. Both the standardised AT-SPI bindings and all of its dependencies need to 
fulfil the criteria for LSB inclusion as described on 
(But note that the page is slightly out of date. The license criterion was 
found to be self-contradictory because the LGPL terms cannot be described 
as "no strings attached". The FSG board still needs to release a new wording 
for the criterion.)

So what exactly are the runtime and linking dependencies of the ORBit2 
bindings for AT-SPI as shipped in current distributions?

For all of them we need to evaluate whether they are
a) fulfilling the criteria, or
b) intended to be excluded from the AT-SPI standard (then we need answers for 
point #2), or
c) about to be removed (then we need answers for point #3).

The following is a sample evaluation of ORBit2, and it shows problems:

* Demand: It is widely shipped, but some distributions plan to get rid of it.
* Best Practise: Its use has been labelled "deprecated" by GNOME
* Stable ABI/API: OK
* Dependencies present: ?
* Upstream Cooperative: There are no upstream maintainers.
* Distribution Maintainers Cooperative: Not sure
* Distribution patches: Probably OK
* Internationalisation: OK
* Resources: Who is going to do the work?

If you can provide me with complete and convincing answers in all cases, then 
I will use those at the LSB meeting. Otherwise I will mainly collect more 
information on how the LSB exactly works, and report back here.


More information about the Accessibility mailing list