[Accessibility] Can you join an FSGA Call next week?

Wed Oct 25 12:08:08 PDT 2006

Thanks, Ian. We would like to ask you to join us on our next regular
FSGA Telecon, which is next Wednesday, November 1, at 14:00 EST / 13:00
CST. Please feel free to invite anyone else in LSB who should perhaps be
part of our conversation.

During our call today the FSGA approved Bill's draft statement (below)
as sufficient to explain our notions of how libspi can become an FSGA
standard in support of accessibility. So, we now have a draft document
that can help move the discussion forward, we think. Please feel free to
share with LSB.

Janina

Ian Murdock writes:
> Sorry, I forgot to respond to Janina's message. I'm at the FSG Printing
> Summit today, so I can't do the call today, but I'd be happy
> to join the next one (or to set up a call to specifically discuss this).
> 
> Sorry again,
> 
> -ian
> 
> On 10/25/06, Bill Haneman <Bill.Haneman at sun.com> wrote:
> >Attached, my "page" in its current state.
> >
> >Bill
> >
> >
> >GOALS for LSB/FSG standardization of AT-SPI interface for a11y
> >
> >BACKGROUND:
> >The "Assistive Technology Service Provider Interface", or AT-SPI, defines 
> >a set of client-server interfaces by which assistive technologies can:
> >(a) access information about running applications via query,
> >(b) receive notification of changes to the state of those applications and 
> >the component parts of their         (usually graphical) interfaces, and
> >(c) interact with those running applications and with the desktop I/O 
> >system on behalf of the user.
> >
> >Assistive (or Adaptive) Technologies provide supplemental or replacement 
> >interface modalities for users who cannot use the computer most 
> >effectively via the standard user interfaces (both hardware and software).
> >
> >By its nature, AT-SPI is cross-process, requiring RPC/IPC (remote 
> >procedure calls/interprocess communication).  The version of AT-SPI 
> >available at present uses CORBA as its wire protocol, and the native 
> >client and server ABIs are defined by the application of the CORBA 
> >specification to interfaces defined via AT-SPI's Interface Definition 
> >Language (IDL).  The Object Management Group (OMG's) CORBA specification 
> >defines a standard set of bindings for multiple languages such as C, C++, 
> >Java, and Python.
> >
> >However, CORBA as a technology is relatively unloved in the desktop space. 
> >It has few supporters within the Gnome developer community, where it is 
> >widely considered deprecated; and its adoption has historically been 
> >actively opposed within the KDE community.  Another IPC technology has 
> >been developed with input from both Gnome and KDE, and is known as D-BUS.
> >
> >While D-BUS is not yet a drop-in replacement for our CORBA technology, 
> >there is motivation for migrating AT-SPI to it in the future, or for 
> >providing a D-BUS workalike which exports interfaces which are API 
> >compatible (though not ABI compatible).
> >
> >Unlike many FSG standards, AT-SPI is of limited use without complete 
> >interoperability.  Whereas most LSB ABIs provide client applications what 
> >they need simply by being available on the platform, AT-SPI is only of 
> >value to its clients if it is implemented, as a service, by a significant 
> >proportion of the platform's other applications.
> >
> >OUR PROPOSAL
> >
> >In face-to-face meetings of the FSG Accessibility Workgroup, and in 
> >follow-on discussions, our plan of record for allowing AT-SPI to enter an 
> >FSG standardization process has been as follows:
> >1) We wish to make the IDL-defined interfaces in AT-SPI the normative part 
> >of the interface.  These IDL files define interface names, methods, 
> >parameter types, and, where feasible, semantics.
> >2) Recognizing that interfaces can only meaningfully be standardized if 
> >they can be validated, we intend to conformance test against specific ABIs 
> >derivative of the IDL.  However, knowing that the presently existing ABI 
> >introduces dependencies which are not in the long-term interests of 
> >interoperability and cooperation, we wish to propose to explicitly plan 
> >for other, parallel, conformance tests with alternate ABIs in the future.
> >
> >Our goal is for future platforms to be able to conform to our AT-SPI spec 
> >without requiring that they be ABI-compatible with the existing 
> >implementation.  This is of course a weaker guarantee than what LSB 
> >normally gives, but realistically we anticipate that since we will want to 
> >define an acceptance process for alternate ABIs, the number of such ABIs 
> >in existance will be small, and clients will at most need to re-compile 
> >some fraction of code for compatibility.  In fact virtually all of the 
> >current clients of AT-SPI access it either via Python bindings (which can 
> >be imported at runtime from different ABIs in a client-transparent way), 
> >or via a set of C wrappers called "cspi" (which for technical reasons we 
> >do not wish to propose as our ABI); this means that in practice a client 
> >may only need to re-link or import a different symbol set in order to run 
> >in either ABI environment.
> >
> >
> >
> >
> >
> 
> 
> -- 
> Ian Murdock
> 317-863-2590
> http://ianmurdock.com/
> 
> "Don't look back--something might be gaining on you." --Satchel Paige

-- 

Janina Sajka				Phone: +1.202.595.7777
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada--Go to http://ScreenlessPhone.Com to learn more.

Chair, Accessibility Workgroup		Free Standards Group (FSG)
janina at freestandards.org		http://a11y.org