[Accessibility] Accessibility Conference Wednesday 1/26/2005 AT-SPI
jgoldthwaite at yahoo.com
Wed Feb 16 14:50:34 PST 2005
Accessibility Conference Wednesday January 26, 2005 -
Barriers to Adoption
o ORBit2 or other CORBA-compliant ORB
o Bonobo (remediable)
· Performance concerns
o Protocol-based concerns are addressed by ORBit2's
· Competing RPC protocol
· Alternatives to making CORBA as the validatible SBI
o Promote cspi and provide alternate back-ends - take
out the CORBA back end and use cspi
o Replace CORBA with DBUS
o UNO instead of CORBA
o Make the IDL normative, and allow alternate ABI
conformance vehicles AT would have to know which
binding they were talk to, but wouldnt need to know
details of transport
· Pros/Cons of each
o Cspi cons: bad for managed runtimes, handles
internal cacheing, not designed to be universal. If
you have a superior caching mechanism, you can turn
the Cspi cacheing Few AT products are using Cspi
o Cspi pros: few dependencies in the ABI, already
exists and is used by some AT - they dont depend
on much, just opaque pointers from; it already exist
and it is used by some AT products; it is commonly
used for validation suites.
o DBUS cons: does yet meet requirements, not yet
sufficiently complete. Relying on Michael Deeks exp,
Doesnt support remote objects, there is no IDL
compiler. Not sure it does as good a job
- Jonathan- DBUS doesnt handle networks, DBUS
designed to provide local bindings which do their own
marshalling and de-marshalling. It was designed for
- it could be used by standard runtimes?
Harald- I have a full blown DBUS to , can have arrays
of DBUS types, there is an IDL compiler in
development. Designed for local bus communication.
You can have network transparency but have security
problems. There is a plan for authentification. Uses
virtual domain sockets, designed for streaming data
Every application can open a DBUS server on another
socket. With CORBA you have to talk trough ORB which
could be a bottleneck.
Peter- DBUS is the direction we are going in for
freedesktop.org. We should enumerate what additions
are needed in DBUS to make it a valid alternative.
Janina- off the record,[ I see what we are talked
about, there is a tension. We need something now/
We can have 2 version that can make it better. If we
stay with CORBA it will be faster but it will take
someones commitment to do it. With each item we need
to know the amount of effort in FTE. Also who is
going to do it so we have some estimate of when we can
Peter- we need to know what the migration method if we
start with CORBA and go to DBUS. We need to take de
facto standards. The KDE folks have be working on
this for over a year. Whether we do it now or in the
break out we need to answer.
Janina- the precepice is possible but it is acceptable
o Designed for simpler localhost communications. So-so
for managed runtimes. No IDL compilers available.
o DBUS pros: very few dependencies
UNO is used in open Office, everyone is shipping it.
It is a mature interface and it meets our criteria.
It is said to have good performance. It supports IDL
compilation. It is the closest thing to a drop in
replace for CORBA.
Dont think KDE would like to have an UNO dependency
instead of a ORBit dependency.
Peter- not everyone is shipping it, the PDAs arent
Will- isnt this class of applications like OO one of
the applications that will provide traffic for the AT.
Bill- Thats true, we could use an ?UNO to UNO bridge
and that would improve performance for OO. It would
be more effort for OO to stop using
Ed- can UNO be used separate from OpenOffice.
Jonathan- I looked at it and it hasnt be done yet but
Many worlds standardize on an API but provide for
multiple certification ABIs . Dont lock into on ,
This is what you need to application to speak but
implementation would be independent. Would have to
change source code, just load a different set of
binding. In the future if alternate protocols are
mature, it is possible to take the existing ABI
validation suite and modify the stubs and validate new
If you change your communication method, neither the
application or the AT needs to know it. We have a
fast path to get a solution but we dont lock
ourselves to one technology. It would allow us to get
a spec out and meet
Con- Novel approach, Short-term we would have the
ORBit dependency. But would be eliminate the
dependencies later. I
Peter- we have future proofed ourselves, but we need
to keep in mind the practicalities of implementation.
Current AT works in a CORBA, if we switch to DBUS,
what happens to my version 1 of Gnopernicus.
Bill-have path to validation path that is CORBA.
Peter how does Gnopernicus connect to the DBUS
Bill- our applications are not speaking CORBA, they
are make calls to a library. You have Python to CORBA
bindings that would be switched for Python to DBUS
Peter- we need more precise definition of what is
needed. We need to do the enumerations.
Al- as a long time salesman of abstraction, I have to
second what peter said. You dont have an abstraction
until you have two instances. You are talking about
putting the translation in a layer. W3C has had
problems with this in the DOM.
Bill- I wouldnt want to hold our spec until we have
the second implementation. If we have to wait on the
second, we havent
George- you are saying for version 1 the ABI would be
Bill- wed set the validation for CORBA first, with
the plans for addition validations for other methods
Olaf- I agree with Bills suggestion since it allows a
way to have a de facto standard that is working
without saying it is what has to be used in the
future. Needs for imbedded device. Currently we have
screen readers using the Gnome libraries, no problem
with that but dont want to ship Gnome with all
if so we have a good solution.
Peter- there is merit to your approach but I would
feel better if we had a clearer exposition of how it
would be implement. If Harald could give us an update
on DBUS development. We need to have some confidence.
Harald- DBUS is currently a prototype, Will probably
have to start over cleaning up links. Probably will
take one person, half a year.
Bill- Will you have an IDL compiler? If you make IDL
normative, you have to have a rule based process. I
would like to see the stubs generated by an IDL
compiler, rather than a programmer.
Harald- ID for each object, gives you removes need
for remote reference counting.
Bill- Remote reference counting is part of SP/API, we
could deprecate it eventually not soon.
Harald- call back?
Bill- in CORBA it means that something has happened
the, the other cant tell if its just a still widget.
My concern is about everyday problems when objects are
Jonathan- when would a program want to keep track of
a widget when if had terminated?
Bill- if the objects state change, destroyed, certain
calls will be have differently.
Jonathan- would it be an application error?
Bill- it wouldnt be considered a logical error,
because things are going on in different threads, you
are going to be trying to contact a widget after it
has gone away and the notification hasnt gotten to
Bill- the notion of a lifecycle model is pretty
essential to objects. We could not. use two different
lifecycle model. We need to have Ref UnRef.
- what about requirements on applications. How to
handle finding relevant information.
George- problem is keeping cost of verification down
Bill- I think we can make them stubs look the same so
that the AT vendors dont have to have change their
Peter- the verification is for the platform vendors,
not the AT.
Will- normalizing on ABI is a great idea. Main thing
is how you are going to do registry discovery.
Bill- the ABI doesnt cover discovery.
· Recommend one or several strategies
· Give a summary of the expected results
· Name the next steps to be taken
· Delegate the various tasks
How to develop a plan for validation while having
capability to move to better technology later and
while requiring the minimum change to current
applications and AT. We may not be able to achieve
binary compatibility. If not we may have to need
recompile or different library. Not greatest case:
some changes to code and recompile. Worst case
major re-write of AT applications.
We dont want to standardize in a rigid way on the
current AT-SPI. That would level out imbedded Linux
and other non-desktop versions. We want to be able to
improve our protocols in the future for better
Will- could Harald give us an overview of DBUS so we
know more about it.
Harald- KDE had CORBA backend but - wanted reusable
components. DCOP- communication Desktop bus so
applications can share information. Forked into
kernel so you have 2 DCOPs on
Heavily optimized for messages on a local system. Can
work on sockets but mostly apps. Applications can
open a new bus so they can transfer data outside the
session bus. You have recipient and sender. Can send
message and wait or
Does not require toolkits, no dependencies. DBUS is
always used native. CORBA has wrappers that you have
generate. DBUS natively wraps into the toolkit, uses
its native data types. Easy for programmers to
It is still under development. Kernel, desktop and
other groups are working on it. IBM supporting it,
Disadvantage- not there yet still focusing on
Will how does discovery work
Harald- you connect to the bus and get and address.
There are well known services.
Bill- what bus do you get?
Harald- you get a session bus, its specific to your
Bill- have same problems as Bonobo with remote
activation. E.g. su
Harald in theory c
Jonathan- lock down various parts of it, working on
policies for this. Consensus using same api for the
remote network, not the best thing
Bill- from AT stand point everything is remote. You
want it transparent. Dont want screenreader to use a
different model on a remote application. Want to have
the same for both. We want to preserve the same
interfaces and remote, at
Harald said it looks native, CORBA takes IDL and
compiles it to your language binding. DBUS bus take
these bindings a step further. DBUS binding if you
are using Glib it delivers Glib code, - it binds to
the toolkit not just the language. Each of these is
an ABI and subject to verification.
Jonathan- no, it binds to ABI
Bill- problem to standardizing to the protocol is that
it ties you to that method. Need method for adding a
legal protocol to the system. Its easier to interface
between two protocols
Stewart- if I are programming, you write code to the
API or code to the protocol. Not both.
Jonathan- Code to API
Bill- strength of standardizing on ABI- were talking
about a IPC method, can create bridge
Stewart- seems like contradiction
Bill- youre not going to code to the protocol.
Youre free to bundle the library. The key is whether
there are applications there that respond to the
Bill- if you are writing an assistive technology, you
want to know that the protocols are there. If
question is application will run, you need to have
the protocol to be there. The thing that is critical
to success is the protocol being there.
Will- analogy- Xwindows- X protocol for how apps talk
to server. Do libraries speak the protocol correctly.
Discussion is whether we are standardizing on the
protocol or the ABI.
Bill- it would be best if there would be several
protocols that are compliant. Even CORBA protocol is
not always using standard methods when in ORB. There
as one protocol for ORBs talk to each other. Another
for the ORB byte stream. Its not easy to define
Stewart- not disagreeing but its unclear. Protocol
required for proper interoperability. The
Will- when start talking about things at CORBA level
marshalling, demarshalling, dont want to know about
Bill- once youve written you application, you want
your validation to cover API and protocol check.
Passing ABI test, lets me know I can load the library
and do stuff. The protocol test- know you can talk.
Protocol testing need more difficult testing,
Spec- write spec is entirely IDL. We invoke other
specification and that defines a binary that is
testable. Describes how feature set and API. Another
part of spec says how we turn the API into an ABI.
Stewart- will have to list ABIs that are called.
Bill- may be ABI for sparc, others for Intel
Heard where you were being vague enough to convert
API. Two APIs ?
Bill- I distinguish between an ABI and a language
If I were to talk a compliant ORB
with C++, there is one correct set of bindings for
Jonathan- perhaps were a little to into the details.
Trend is towards more DBUS use. Dont
Bill- purpose of dialog is to see how this fits in to
current and how we can move forward later. Have a API
that is compatible with direction
Stewart- there is going to be a Corba that produces
Harald- youll never find a API
Peter- Corba in version X and DBUS in version Y.
preserving application compatibility is important,
Bill- no application speaks AT=SPI, applications are
insulated by at least one layer.
Peter always said that accessibility should feel
natural to the programmer. There are few AT products
and many application can put more test requirements
Bill- when we say applications we mean the mainstream
applications such as productivity suites, browsers.
Will- you mentioned Cspi. Seemed like all the a thin
layer would smooth out some complexity.
Bill- Cspi is only a sugar coated wrapper. It would
be easy for AT but make it hard for Python apps. If
we specify at the level close to the AT, there is no
interoperability guarantee. You will have problems.
I authored Cspi and dont think it should be used as a
Will- from looking at ORCA code, there are problems in
Bill- there are some problems there that are
implementation dependent. If we can
We raised the activation question.
Jonathan- its a detail of the protocol we decide to
Bill- its not controversial, or
Peter- not concerned with whether we deal with it
today. I liked the atom idea. Im concerned about
Bonobo being a requirement.
Bill- Bonobo refers to 3 things- Activate,
BonoboUnknow which has only 3 methods.
Its easy to reimplement that using our own code would
eliminate the dependency.
Will- the most important thing is that discovery and
rendezvous have to be specified.
Bill- there is query and there is activation. If its
not running, how do I invoke it. Dont want all the
programs to have to know the address of the program to
Mark- we seem to be saying the DBUS is the way to go
but will take long. How much longer is it going to
take:? Will it really save us time if we have to do
Peter those are things we need to enumerate a long
with the EFT- move that we do the enumeration.
Peter- what does security mean?
Harald- means different things- security for local
login vs. remote p
can we do it with network transparency; we
have a mechanism to do that in a CORBA.- would need to
recreate in DBUS
Mark- we dont have network transparency now.
Bill- it could be hacked up in a couple of hours,
Peter- in CORBA it is small well organized problem, in
DBUS has not been defined. Harald agrees.
Janina- if it is being adopted across the industry, -
its not an accessibility
Bill- its a dependency problem
Peter- Industry wont support it if there are too many
Bill- looks like DBUS a
Olaf- rephrase to time to implement question , if we
want a toolkit neutral method, we need to look into
where- who is going to develop things needed in
toolkit neutral way.
Bill- Im not aware of ORBit having any dependencies
other than glib. Anything that is associated with one
toolkit and not another. The library dependency
Harald- glib only, if you can get the X? dependency
down we could live with it.
Bill we can get around many. We need to look at
AT-SPI linking policies and see if we can limit the
things it pulls in.
Olaf- its great if Orbit2 has fewer dependencies, it
would be much easier to get acceptance in KDE. As
long as we have some
Janina- its is break time
George- if had to go use a screenreader, Id want it
to be stable and work on more than one version of
Bill- we could have a bridging mechanism to handle the
deprecated protocol. You could run both in the same
box. If you had 1.0 AT youd want it to coexist with
1.8 version AT.
Bill thanks us for working through the problem.
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
More information about the Accessibility