[Accessibility] LSB nature and inclusion criteria
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