[Accessibility] Accessibility Conference Thursday AM 1/27/05
jgoldthwaite at yahoo.com
Wed Feb 16 14:52:33 PST 2005
Accessibility Conference January 27, Thursday AM
Keith Packard- HP
Buddy Erie PA
AT-SPI Outcomes of discussions
AT-SPI IDL is primary to our spec foundation API
- review IDL to make sure all should be included in
We have to validate against a ABI, we want to capture
this of AT. If so, AT will a certain set of services
and behaviors available. Doesnt say SR built for one
platform will run on another but does guaranty that
the logic will not need to be check. Assistive tech
needs to know its logic is going to be valid and stay
so. Also would like to be sure we dont have
re-compile thats where we get into API.
Conformance requires that we contain ABI components.
Conformance and validation requires ABI component(s)
Clients require client-binding consistency
Dont want to have to change one binding call with
another across the whole product. At worst they can
do a recompile and run in another environment.
Functional requirements/interoperability require
If you dont have some have protocols that are the
same you could have bindings that look the same but
We wish to separate protocol from client ABIs because
there is value in allowing additional protocols in the
Want to discuss the ABI separately from the protocol.
Would allow us to change the protocol in the
future. Thus we want to separate ABI validation from
API validation. Have to make sure clients and
distributors understand what we are offering. Need a
light weight method of changing protocols. Should be
able to add protocols in a dot release, not wait for
2.0 or 3.0. Need to do this within FSG procedures.
Should begin to define acceptance criteria for new
protocols, and submission process
Should define back-compatibility and interoperability
criteria. (dont want to say there might be another
protocol without give idea of what backward
Acceptance criteria will need to reach up to the
bridge/server side, to ensure full functionally
compatibility with existing architecture and legacy
GAP. Want to be sure that we can swap bridges if move
to another platform. If change protocols, you have to
have new bridges.
Larry- Concerned about bridges, agree that they would
need to replace but dont know how we could know what
all the bridges.
Bill- need to have public review and interop criteria
Peter- focus on transfer protocol, also need to think
AT side- acc
Bill- to paraphrase- We should as part of spec process
we should include language of how the spec will be
Al- another paraphrase ideal compiler in ideal work.
Access contract between AT, is based on having a
schema of what the information is that we need to
Bill- That is how do we extend the interfaces
Al- youve done a great job of summarizing.
Strawman of 1.0
Include the IDL a set of blessed client bindings and
existing CORBA protocol.
- reason for blessing specific client bindings is to
aid in the new protocol acceptance criteria -
validating useful because this is the specific
contract that the AT will work with. We dont know
how many APIs there will be but we want to come up
with some basic bindings you can rely on. Will
include the CORBA protocol. Blessed bindings
define what our protocol has to fit. Despite my
concern about the Cspi is the right binding, it may be
the right one. X exposes the guts of Corba. It
would best to have compatibility to Cspi rather then
to the CORBA C bindings. Aside- Cspi C binds dont
have any Gnome dependency except glib. It is already
to write AT in C without being dependent on anything
in Gnome other than glib. The author doesnt have to
deal with Gnome class.
Harald- Gnome things are not exposed but glib is very
Bill- youre saying that glib is not a trivial
dependence. There maybe a trivial Tango
Actions for strawman
- Review IDL for inclusion Will, Peter, George,
Bill, Harald, couple of others.
- Identify the problem dependencies- Harald, Olaf
- Identify which problem dependencies might be excise-
Bill will recruit group to do this, including
Jonathan. Need to see what dependencies are pulled
e.g. libbonobo tends to pull in all of Gnome. Might
be able to remove, Cspi tends to pull in everything
from both sides. Need to go back and prune.
- Assign resources to excise refactor code to
encapsulate or remove those dependencies.
- Start making contact with FSG desktop group
Stewart will do this
- looking at changing activation method, ref-counting,
and dependency triage on Gnome ABI stability
guarantees. Need to be sure that we dont do
anything that breaks Gnome desktop Jonathan, Al,
There are also some constraints on us from ,
Olaf- note on abi stability of KDE, we are about to
do new release so we could break binary compatibility.
Harald has made
Harald- we have until end of year make binary
- we dont have an activation ABI for 0.1, the one we
have has lots of Bonobo dependency. Do we want to go
ahead without saying something about activation? How
much deprecated stuff we need to leave in place not to
violate our Gnome contract?
- What testing harnesses techs should we use? How
much do we care about dependencies of our validation
test binaries. May be better to create our own test
harness. If we have new arch/ chip set but our test
suite hasnt been ported to that platform, that seems
like a problem. If our validation suite requires
libbonobo, that means they have to have a working copy
of libbonobo for their platform. Problem but how big
- Olaf- I would care about the license and not
dependency since it is test and not concerned about
shipping. Question whether test suite would run on
imbedded devices. Bill- test suite has be port
- George- example lp support, S390 if I have a
imbedded device, the developer has to be responsible
for porting the validation suite.
- Bill one blind what if the person is a open
systems group that doesnt have the resources to
- Al- sounds like a valid economics issues for
imbedded products, we may want to duck that question
- Peter- more general topic- we talked yesterday about
because of the thinking that DBUS is the way we want
to go in the future. We should have a group to prove
the DBUS is going to be valid alternative. Want to
have before 0.1
- Peter- not a gate for the spec but we want to get it
as an action item
- Olaf if we have validation suites on Gnome, and we
want it on imbedded- do we have to create new
validation suite based on new principles? No, good.
In Keyboard, how do we proceed with our tests. What
format does FSG require.
Stewart- it has to be useful.
Bill- sometimes the test binary is the acceptance
tool. Is there some format for test suites
George- gave example of Posix test
Bill- what does this group or subgroup need to
produce? Dont want to write test suite and find it
does not meet the needs of FSG. Want know what I must
do, what I should do?
Stewart- FSG hires someone to be the 3rd party
certification authority. Submit big set of journal
listing which they have automated system to parse. We
are used to using tests as our framework. It would be
nice to use the same tool that we are using.
Bill- someone who likes tests should take an action
with someone who knows the xxx, to write a few tests.
Doug- we spoke early on that there are some actions
that can not be tested automatically. We need to
product script for the manual portion of the test.
Al- The soft spot is that the DBUS fork should be a
Bill aside- one thing for advancement of AT-spi,
independent of everything maybe we should use DBUS as
Jonathan- good idea, t
Bill- Ill take an action with some others to begin
George- we talked about doing activation with the X
Bill- its easy enough for discovery, but to deal with
replacement and recovery. I want to ask if DBUS can
do that for us already. What we have is limited to
local host and as does DBUS.
Will- the philosophy behind server model, are there
enough existing products that use the features and
Bill- before we commit ourselves we ought to see if
its what is needed. Thats are hard question. Any
solution is going to have holes in it.
Al- On using Atom on Xserver, I dont want to freeze
the discussion with that. This is a much more
universal design so we need thing about it and take
Bill- LSB is not about writing new standards but about
finding what works and making sure things are
compatible. We want to be able to point to x at the
1.0 release. Want to be to make changes to the API.
Peter- Is this API good enough- well take this an
action item. We know this API is rich, robust and
extensible. What we are doing is what Apple doing
with their 10.4, it is almost a perfect subset. It is
also what Microsoft is doing in Longhorn. I have
reasonable confidence that as long we have a good path
for extending our spec, that we okay for 0.1
Bill- we have 4 ATs written to this API which cover a
wide range of modalities. Because of screenreader, we
have two implementations for the API. Weve shown we
can have an alternate
Will- you can do screen readers but
Al- Have to ask you to live in Hope, We have stuff in
W3C that will live in the real work . There is enough
consensus to move forward. If you -- Testimony on
the web is that screen readers dont have data
validity with the presentation. This model will take
us to something developer can trust.
Jonathan- do you know Acrobat is doing their
communications with the spi
Peter- they are using ATK, they have some g widgets
and some proprietary widgets. They have not made a
statement to there commitment to supporting it at the
executive level, they have a full time engineer in
Bangalore that is working on it. They are doing it on
the Mac and all the other platforms,
Mike- what do you mean by compelling
Will- I do believe that this is the right model,, but
what I mean is the screenreader user allows the user
to use the products and
Mike mainstream AT vendors arent here
Peter- they dont want to take risk on platform. Now
that there are open solution, they dont want to come
because they dont see how they can make money versus
good open source products.
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
More information about the Accessibility