[Accessibility] AT-SPI and CORBA discussion from February

[John Goldthwaite]

Here is the discussion from  2/4/04, 2/11 & 2/25 concerning CORBA and
AT-SPI, sorry I didn't think to do this last week.

Accessibility Working Group Meeting February 4, 2004

Doug Beattie
John Goldthwaite
Bill Haneman
Peter Korn
Janina Sajka
Gunnar Schmidt
Matthew Wilcox

Janina- check on a11y.org, calls to each member, talk to Mario about having
discussion on Shared I/O on Feb. 11 also Michael Meeks Michael at ximian.com

Last weeks minutes approved as revised via email.

Janina is work on calling everyone. No news on licensing from U. Wisconsin.
NSF has requested a formal proposal from us for the meeting. We will work on
this on the list this week and try to get it back to NSF next week. This is
good for two reasons. We need to have a meeting this year and we need the
recognition that comes from having the funding from an agency like the NSF.
The meeting will help us get broader participation. Janina will post the
letter and past documents on the website so we can discuss this. Janina hasn
’t talked to Mario about meeting next week. Mario knows all the people and
is capable to get into the code.
Bill - the support for Braille-tty is an open issue. Current licensing of
brailletty is a barrier to support and adoption.
Janina- Dave Melke co-maintainer of Braille-tty should be involved.

Bill- Proposal- take AT_SPI subset. It is now a set of API’s in Gnome. "One
layer, specified in Interface Definition Language (IDL), would be the best
candidate for standardization. The current ABI implementations of this API
(for which the IDL is the 'normative' specification) uses CORBA. We have two
existing implementations of this API/layer: one is fully free (in C, under
LGPL, with LGPL dependencies), and the other is LGPL-licensed but requires a
recent Java virtual machine and thus has a dependency that is not fully
'free'." There is a layer (IDL definition interface definition language)
that is CORBA defined that would be a candidate for a standard. One
implementation is fully free and has no dependencies. The other is JAVA 
.
Bill- from the point of view of AT, it’s the AT layer that’s the most
important to standardize. IDL is a generic method for describing an
interface without resorting to a programming language. "CORBA is the
best-known back-end for IDL, and at-spi's IDL conforms to the CORBA
standard. There are multiple existing software systems that can parse IDL
and turn it into code. [including the FOSS ORBit2]."

Janina- is i18n using IDL as a mechanism for internationalization?
Doug- No, we can talk to them about it. They also meet on Wednesday 2 hours
before our meeting

Bill- IDL itself does not have any direct international influence. You have
to think about which parameters in the interface need to be localized. It
would make sense for the international groups to have a look at any
standards. Likewise, we should be looking at what they are doing.
Janina- this was mentioned at the FSG meeting.
Bill – we’re talking about an interface that is seen by the AT and is
exported by the OS. The best candidate is a layer that is defined in IDL.
This means it is not specific to a programming language and is leveraging
the CORBA standards. It is also a good candidate for migration to other
implementations. We could put it forward as a binary standard but could also
allow other alternate non-binary standards. If we needed to do something for
embedded Linux which does have all the things that are in the desktop
version. It wouldn’t be the same binary but it would be straight forward so
that the same assistive technology could run with it without modification.
Janina – who’s standards are CORBA and IDL?
Bill- Common object request broker architecture (CORBA) - OMG- Object
management group. Implementations of CORBA exist under all kinds of
licenses. This layer has been implemented in C for the Gnome project and in
Java as part of the bridge in the AT-SPI project.

Question whether we want to do an API or ABI

Gunnar- KDE will use a bridge from the Q-accessibility framework, so that’s
no problem. The only problem is that CORBA is not liked by KDE programmers.
Using CORBA for inter-process communication for KDE 

Bill- we need an interface that is not specific to a platform. I don’t think
we have another good candidate. From the point of applications, the
programmers would not have any direct contact with this. Developers of AT
would be using an API based on CORBA. Depending on the language you’re
programming in, CORBA maybe obvious or pretty well hidden. Its messy in C,
but better in C++. For AT you need rich inter-process communications. Gunnar
is making a good point, if we have a binary standard, it will be based on
CORBA.
Doug- we’re about a binary standard that can be validated.
Bill- there 

Doug- you’re saying nothing else exists?
Bill- yes, the
Peter – Its worth exploring the other alternatives, e.g. DBUS
Bill- they are not rich enough, they don’t provide enough facilities for
inter-process communication. There is not an object oriented DBUS

Gunnar- currently KDE uses DCOP. It is planned to use DBUS in the future.
Peter- is it anticipated that DBUS will be enriched for IPC?
Bill- DCOP is limited, they are thinking of creating MCOP which would allow
richer for expressing object-oriented APIs, has seen very limited adoption
and is still poorly matched to our needs.
Doug- with LSB 2.0 a major portion is the addition of C++
Bill- that may argue more for CORBA since there is a good interface to CORBA
in C++. But that’s a language we need a ..
Peter:The only other possibility is JAVA-RMI. [Bill note's that this is not
free, therefore not a candidate.]
Bill - CORBA allows Java, Python, C++ and other libraries to communicate
seamlessly with each other. You are saying that particular CORBA services
are available to the language and libraries.
You’ve got in process calls for ABI, you have binary standards for FTP, DNS,
Sockets. We’re proposing an ABI standard that has all the features of API
accessible via IPC. >From the point of view of the application, the fact
that its based on CORBA is not important, it’s the services that are
available.

Matthew-
Bill - At the layer we’re validating
Doug- we’ve been standardizing at the level the application are running
Bill- that’s not the layer where interoperability needs to be preserved. It
’s at the IPC level that we need to standardized 
 AT vs. application 
 we’
re
Bill- we’ve got applications written via different libraries all of which we
are trying to make accessible. All can’t link to the same 
. What is being
proposed for standardizing is the IPC. Whatever library is used, it needs to
use the lower level of IPC to talk to the AT. It’s far richer that things
like HPG
.
Janina- we also have to look at the SPI 
. Running out of time for today. We
need to get Michael in next week. Are there other people from KDE that need
to discuss this? If DBUS is not ready to provide this kind of behavior

Bill- there are two ways of viewing IDL – object-methods interface and
generator of code via parser.
Matthew- will talk to some of folks and try to get them on the next call.
Peter- focus on the information that has to be exposed for the application
to be accessible. This is a large stack. First think about information that
every application needs to expose to support accessibility. .. Parent-child
relationships 

Bill- we don’t want to get into that next. focus on the AT first. This a
description of the types of services
 We want to go toward an ABI, there is
the API, there is an ABI that can be tested against. There could be other
ABI implementations for the API 
. what I’m taking about is – from the point
of view of the AT. If you start talking about the applications, it can be
confusing. We need to look at one side first.
Peter- Look at the information the desktop must provide.
Bill- we want to standardize on the information stream. We’re not working on
certifying applications for their compliance.
Janina- we need to have this conversation with enough people to have the
buy-in for the standards.
Doug- you have to be able to validate and verify. It’s useful to distinguish
between the API and ABI.
Bill - Often standards level some items undefined. You validate against the
specific back-end [implementation which] we provide – if I write an
assistive technology that runs on a conforming platform, it should be able
to run on others. What we’re certifying is that the desktop has a basic set
of services that conform to a single client-side Service Provider Interface
(SPI). The advantage of doing the standardization at the IPC level is that
all the languages and libraries can use it.


Stewart Anderson
Doug Beattie
Sandy Gabrielli
John Goldthwaite
Bill Haneman
Randy Horwitz
Earl Johnson
Peter Korn
Janina Sajka
Sharon Snider
Matthew Wilcox

Janina- check on a11y.org, calls to each member, talk to Mario about having
discussion on Shared I/O on Feb. 11 also Michael Meeks Michael at ximian.com

Corrections to the notes. Bill will make corrections off line. We'll hold
approval of last week's minutes until next week.

Janina is work on calling everyone. No news on licensing from U. Wisconsin.
NSF has requested a formal proposal from us for the meeting. We will work on
this on

Bill- Last week, Gunnar commented that CORBA is not liked by KDE
programmers.
Janina- We need to make sure we have those comments. Bill- Stewart may have
some comments as we're proposing to do something slightly different from
prior LSB efforts
Janina- Was not able to do some of the action items due to workload at AFB.
Talked to NSF: if we get proposal back in a month or so, we can have a
meeting in the fall. Doing a demonstration this afternoon for Congressmen on
DAISY technology. We were recapping what LSB has done vs. what we are
looking at with AT-SPI.

Bill- DBUS shouldn't enter into consideration. We did mention it last week
but it is not relevant to our discussion since it has doesn't relate to
AT-SPI and there is nothing on anyone's roadmap to make it relevant.
Janina- could be 

Bill- I don't think its technically possible,
Janina- lets recap the discussion on AT-SPI. Bill- Does very one have
familiarity with the GNOME Accessibility architecture? URL-
developer.gnome.org/projects/gap Link in section called documents- gnome
accessibility for developers The diagram is Figure 1 about 7 paragraphs
down. We're proposing to standardize on the platform layer. This diagram is
out of date, ignore "Modified Window Manager" and "special calls". Even so,
Its an accurate reflection of the layers. For backgroup, we felt that
standardizing on applications and application behavior was more than we
could do at beginning. We could focus on Assistive Technology, the assistive
technology would work to the extent the applications were compliant. There
are lots of reasons that the application area is troublesome, but
applications sh Applications are always in their own process space so any
standardization is going to be in the Interprocess Communications.
Stewart -don't you have to do both?
Bill- need a consistent set of platform services that the AT can count on.
Can't do it at library level, AT may not be written [in a language
compatible] with that library. We need to avoid applications having to
proactively having to interact with assistive technology. We need them to
follow standard behavior. The different toolkits are sufficiently
heterogeneous that we can't count on this. We're not dealing with the
application space at this time.

Stewart- If you talking about an orb, we have a network connection between
these pieces.
Bill- Perhaps, but CORBA and our IDL do not require that the IPC be
cross-host or require cross-network traffic. Assistive technology has been
historically VERY non-portable. We're limited in the AT we have in Linux, we
want to design this so that the AT doesn't have to deal with all the
heterogeneous. We trying to establish a standard at the IPC level as seen by
the AT and make sure that all the applications export information at this
level, sort of a 'glue layer ABI'. There is hope in site for this to happen.
Having an ABI doesn't mean it works correctly. Inorder for a screenreader to
work on a platform it needs certain services. The nature of these is IPC
since this a client server model. It make sense to standardize on the
service APIs, which we refer to as "SPIs", for "Service Provider
Interfaces".
AT don't have to link to C, they can do link to client-stubs appropriate to
their own language, whose exact ABI is dictated by the combination of the
IDL and the standardization of "language bindings" for the specified IPC
technology. (IN our current implementations this technology is CORBA, and
the client binding ABIs are dictated by the CORBA standard.) In this
scenario, ATs don't have to link to a specific Binary ABI. They just link to
some CORBA "stubs". It's the ability to speak CORBA protocols, that way you
don't specify Stewart- You're putting more knowledge of the protocols in the
application anyway.
Bill- Not to a great extent, and it depends on the language you use. In C,
you have "Corba Environment" structures exposed, as a way of providing
exception handling in C; otherwise there is very little CORBA
implementation-specific detail exposed.

Bill- point I'm making is that you don't want to standarize at the library
level. Developer wants to write to an ABI, To do ABI validation, you have to
do standardization at the level of the IDL as expressed in CORBA.
The reason for wrestling with this is that the nature of the service is
different. Application developers need to know that particular libraries are
available. You can rely on API's being there, code works.
However for AT the API's are much more service oriented. It may not be good
to standardize on a binary C level. You want to go one layer lower. If you
validate C, need to validate C++, Python, etc. The advantages- you don't
need to have a validation for all the languages you want to write AT in. It
means you have the potential to change your back end – link against a set of
client stubs that were connect to an appropriate backend. In future could
have...
Stewart- you could have a set of thin wrappers.
Bill- That's what the IDL does for us. The CORBA client stubs are thin
wrappers around a transport/IPC protocol. It's the normative API. The
Stewart- isnt' the IDL CORBA specific?
Bill- its not, our IDL conforms to the CORBA standard but can be used by
others. You could write IDL which was compiled to some other back-end ABI.
You have a layer you can validate against. At the end of the day we'll be
validating against some binding but we don't want to make that binding
normative. If an IDL compiler is conformant with CORBA, we should be able to
"share" validations across language bindings. The interORB protocol, there
are a number of layers in CORBA that have been carefully specified. We can
validate, we're going to say we have an API that we're going to validate
against .. going to pull implementation libraries into the mix or the ..
Stewart- .. want to keep all the other language bindings in mind as well
Bill- writing them in C is tricky, you may get better traction writing AT in
other languages. We're trying to insure that AT written to our spec will run
on any platform that's been validated against our ABI. Practically speaking,
that implies a lot. You can't do this without a lot of dependencies. You
don't want all those dependencies to be part of the standard. If you leave
the dependencies as implicit your okay. 
 That doesn't mean that every
dependency of AT will be met, they tend to have many.
Stewart- How about screenreaders?
Bill- this is about making sure that the screenreader will be able to get
information from the platform. If its written in Python, there are 2
dependencies- api and Python. In practice any implementation of will have a
lot of dependencies. If we link at the library layer you dependent on having
Bonobo, orbit2, orb and other specific libraries on the platform. If all
we're say is that you have to standardize at the client stubs layer, we
don't care what the backend details are. IDL was designed as a way to do API
without ABI. The IDL we use are all CORBA implementation of the IDL. The way
CORBA works is that the IDL is compiled into a thin wrappers around the
CORBA protocol. They are language dependent but they allow these to
interoperate. You've decoupled your IPC from the languages

Janina- we want to go with th, before this accessibility work began in
GNOME, there was nothing in X. Its radically different from the Windows
approach.

Bill- the emerging Longhorn approach is more similar to this, the older
Windows platform is different.
Janina- want the platforms to be able to deliver services needed for AT.
Hopefully we can get enough people in the conversation to reach consensus.
Willy- we need to more discussion on the list to elaborate.
Janina- what will it take to get the discussion.
John – If Bill will edit last week and this week's minutes, we can review it
and ask questions/
Randy- is there some information on the GNOME site that would provide
background so we don't have to send so many messages?
Bill- 
. Conformance problems with ORB, not accessibility problems. You need
to validate each language you write in. AT's are unique in that they' re
interacting with applications written in multiple languages. 
 so don't need
to validate against all the languages.
Randy- is the xxx the layer between xxx in the Diagram
Bill- all those bridges are things that take toolkit specific ABI's and 
 to
speak a 
 there are two sides to the interface, you could also validate
against the application
 need to be conformant
 application writer.
Janina- 
 toolkit developer
.
Bill- architecture allows many different ways to reach a conformant result.


Accessibility Working Group Meeting February 25, 2004

Doug Beattie
John Goldthwaite
Bill Haneman
Peter Korn
Janina Sajka
Gunnar Schmidt
Matthew Wilcox

Last weeks minutes need to be reviewed.
Action items-

Today- step back from Bill’s explanation of AT-SPI and see what we need to
do in the other areas.  We had good questions from members and from Stuart
Anderson on the details.  There will likely need to be more discussion.  How
do we get towards consensus?  This may be somewhat different from what LSB
is used to seeing as a standard.  Other than explaining over and over again
to wider audiences, what can we do?
Bill – if we could summarize the goals and issues that have been raised. We
have it in a narrative form that might be hard to decipher.  If we can state
the goals, the requirements that have come out of the conversation.
Janina- FAQs?
Bill- more like bullet points and a few paragraphs.  The discussion
presupposes some things we’d like to do, we need to flesh those out more
explicitly.  We expressed a desire to have a product that’s not tied to a
specific implementation or to a particular language.
Janina- it shouldn’t be hard to start this discussion on the list.  Other
thoughts?  Do we need to figure out when we need to do a face to face with
other people, such as at Linux World in San Francisco?
Bill- when is it?
Doug- around the first week in August.
Janina- are you likely to be there, Bill?
Bill- August is usually a bit dicey.
Janina 
 FAQ
Bill- I wasn’t thinking FAQ but that may be what we need.  I was thinking of
characteristics of the standard.  If we put this in the terms of
requirements, we may find we can’t meet our requirements for this year.  If
it has 
 validatible, implementable for various toolkits, not just one
toolkit.  The best solution may be more that one ABI or API. Because this is
a pretty complex item, it has elements that are in several parts of the
desktop so we may need more than one ABI.
Janina-  Requiring CORBA seems to raise questions for some people, we need
to explain why this is the right answer.  If there are other solutions,
perhaps someone could come up with a solution.
Bill- We need an implementation that can have components that can replaced
without redoing others.  Every standard does tye in, if you have a
requirement for C in your environment, that will determine some aspects of
the linking loader, bindings, 

Doug- for every version that the LSB does, they get down to the lower levels
such as specific symbol versioning on the libraries.

Doug- that’s not tying to an implementation, just to use commonly used
libraries.
Bill-   there is an element of implementation in the spec.  You are saying I
’m going to communicate in a certain way.
Doug- that’s correct. 
 C library 
  It’s best common practice.
Bill-  
 CORBA had a long soak time.
Doug- you’re going to see how it’s going to work well and be fair and
equitable for everybody.
Janina- this is the question – is it functional for the greatest number of
people and doesn’t break features.
Doug- and it’s not going to cost them anything as far as royalties.  If it’s
the best thing technologically, why wouldn’t people want to do it?
Bill- we’re providing sources, it’s just a question dropping them in.
Doug- having having others (distros and ISV) know that the upstream
providers are going to be around so the features will be maintained with our
group or the distros and ISV having to maintain the item(s).
For example, xfree86 changed its license and now most distros are going to
drop it unless they change the license.  A new source is going may have to
be adopted to keep the licenses compatible.  There should be multiple things
from which to choose from.

Janina- seems like writing it up in plain English is the next step.
Doug – I still want to be clear that CORBA is the right thing to do, its not
going to lock us in.
Bill- we have implementations of CORBA ..  there doesn’t seem to be any
problem with having a free, open source implementation.  Commercial
implementations have existed for years, although it’s not as commonly used
now because of SOAP and XML.  If it’s a question of whether CORBA will be
around, the answer is yes.
Doug: What about copyright issues?
Bill- yes the copyright is open source.  A lot of open source software
relies on the CORBA standard, so we won’t be alone. It makes me confident
that other people have addressed this question and found that there is not a
problem with CORBA.
Use of CORBA is specific to a implementation of an IDL. But the IDL is
expressible in other ways.  If we want to change the ABI we can do that
without disrupting the API’s.  We can swap in an alternate ABI that have the
same semantics and be transparent.
Doug- We don't want to have to deliever any new binaries to make things
work. The discussion/question here, from myself, was that we do need to
somehow guarantee that an ISV can write an application and the binary will
run in the same manner on all certified distributions claiming to support
the standard. The FSG is concerned about making life between ISVs and
distributions compatible. Bill- worst case you’d have to recompile your test
suite.
Bill- didn’t say binary because that’s ABI.  When we’re talking ABI its 

Doug- when I’m talking ABI it’s an application running without problems.
Bill- it’s a slightly different point.  With IDL, we can swap
implementations without breaking the clients.  The ABI will change but the
semantics as seen by the application won’t change.  We may have to recompile
the test suites.  There may be a time in the future where we have a binary
incompatibility such as major version change.  A new technology may come
along that we want to swap for CORBA.  
 The implementation details have to
be shared across the desktop.  The important.. is not at the bindings, its
at the interprocess communications level.  Making changes means making
changes to the protocols.  We’d have to change the tests.  If we test just
one side of the equation, that’s not an adequate assurance that something
such a screenreader will run.  If we standardize at the language bindings,
we could swap 

Doug- it sounds like we need to standardize a several levels
Bill- Yes
 we could confirm that the interfaces are there.  On the client
side we could test the ABI so that the client wouldn’t have to be
recompiled.  The downside- the C bindings would be a wrapper around
something that’s already a wrapper.  If we standardize on the protocol,
because CORBA provides a definitive spec about what a client binding is
supposed to look like, the CORBA binding is not as implementation
independent as we’d like.  It would have some ‘warts’, if we change the
implementation we’d have to make the new software compatible with the ‘warts
’.  The application would have to think it was talking to the CORBA server.

Janina- lets back up to the face to face meeting.  Do Gunnar or Matthew have
any questions?
Gunnar- I don’t have anything to add right now.

Doug – Linux World is Aug 2-6, perhaps earlier in San Fransico
Janina- Bill, where are you likely to be over the next year-
Bill- probably, Gnome Users and Developers European Conference (GUDEC)
Matthew- Linux symposium.org is July 21-24 in Ottawa; I’m on the review
committee for papers.
Doug- many of the LSB people will be there. OLS is an engineers conference
and not marketing fluff at all.
Bill- that might be worth a trip.
Doug- this is definitely not a marketing event!
Peter- Bill, you’re the one that needs to be there rather than me.
Bill- I should be available at that time.
Bill- Gunnar are you available at that time?
Gunnar- I am open at this time.
Matthew- We had no KDE papers submitted last year. Gunnar, you should submit
a paper on KDE.
Janina- we should present a paper on our proposal.  Is the meeting at HP?
Matthew- no, its independent, at the conference center.
Doug- Mats Wichmann is the current head of the LSB, it would be good to
discuss the project with him.  He is with Intel.
Janina- it would be good to have this document completed by then.  We could
present it and see if we have agreement.  If we get agreement then we can go
on with discussions on the test suites.
Doug- how about at CSUN in March?
Janina- there is a lot going on there but most of the Linux developers
wouldn’t be there.
Doug- The technical groups met before the conference started, then for a
couple days during the conference in the hotel suite set up for this
purpose, away from the marketing hype.
Janina- that’s a different kind of work.
Doug- the group brings in a wireless connection so that everyone can
exchange documents and we get a lot of work done.

Janina- I can get the document started and we can see how we can move it
forward on the list.  Any other things we need to discuss?  We will have a
meeting next week.  I hope it’s as good as the last few which have really
moved things forwards.  See you next week.  I’ll be at the W3C conference in
France.

Bill- did you get any good weather in Malaga?
Janina- No, it cleared up after I left. There is a person from the EC that’s
interested in the project.  He is from the radical party in Italy.
Doug- Have you talked to the group from Spain?
Janina- no, I heard that there is a group at ONCE that is doing things with
Linux but I haven’t met them.  Has SUN been working with them?
Peter- not on Linux, we had a project on Java.
Bill - O’Reilly has put all its books on Bookshare.
Janina- That’s great. I need to talk to Jim Fruckterman, they have a problem
with one of the conversion utilities for Daisy.
Bill- if a contact with Tim O’Reilly is useful, he welcomed a meeting.
Janina- there is going to have to be a book about what we’re doing.  Talking
at the O’Reilly conference would be a good place to talk about moving from
the theoretical to the practical.  O’Reilly has always been supportive, we’
ve always been able to get ASCII from them.  Well, see you next week.



John Goldthwaite
Center for Assistive Technology and Environmental Access, Georgia Tech
john.goldthwaite at catea.org