The Linux Foundation is a non-profit consortium dedicated to fostering the growth of Linux.
|
|
Accessibility/Minutes/Minutes20071218
From The Linux Foundation
Open A11y Working Group Conference Call (18 December 2007)
NOTE: These minutes have not yet been finalized. However, an audio archive of the 18 December 2007 call, in OGG format, is available. Please use the audio recording and your own recollections to assist in finalizing these minutes -- errors, attributions, mis-attributions, clarafications and/or corrections should be posted to accessibility@a11y.org
Contents |
Participants
- Janina Sajka (JS/chair)
- Stew Benedict (SB/The Linux Foundation)
- David Bolter (DB/University of Toronto)
- Mark Doffman (MD, Mark/Novell)
- Calvin Gaisford (CG/Novell)
- Bill Haneman (BH/Sun Microsystems)
- Eitan Isaacson (EI/Accesicer)
- Earl Johnson (EJ/Sun Microsystems)
- George Kraft (GK4/IBM)
- Aaron Leventhal (AL/Mozilla a11y lead for IBM)
- Michael Meeks (MM/Codethink)
- Gregory J. Rosmaita (GJR/scribe)
- Rob Taylor (RT/Codethink)
- Willie Walker (WW/Sun Microsystems/team leader for Orca)
- regrets: Pete Brunet (PB/IBM)
For Reference
Preliminary Items
- continue action item on GJR re: vetting audio transcription of PB's comments
- Minutes from 4 December 2007 Open A11y Call approved without objection
Summary of Action Items Assigned at the 2007-12-04 Open A11y Conference Call
- ACTION GJR: mock up template for Open Accessibility specifications by 15 January 2008
- status: in progress; continued
Meeting Minutes
Topic 1: AT-SPI, D-Bus Developements, and Implications for the Proposed Test Suite
One Sentence Introductions
JS: welcome -- many new people on call; debated whether should go around and introduce ourselves -- keep brief, so can get to substantive testing/engineering discussion
JS: chair, Open A11y working group; end-user (screen reader)
GJR: vice-chair, listmaster, webmaster for Open Accessibility working group; invited expert to W3C; end user (screen-reader)
WW: lead on Orca screen-reading project
DB: worked on team that developed GOK; working on various open source AT products
AL: Mozilla a11y for IBM
GK4: work for IBM; no longer work with a11y directly, but still an interest; want to help to ensure that what we began gets done
BH: drafted and coded most of GNOME interfaces including ATK/AT-SPI
CG: work for Novell; starting up new team to do a11y work in mono project -- especially windows forms and moonlight project and the entire GNOME structure
MD: CG tech leader of my team at Novell;
EI: developer and maintainer of Accerciser
RT: director of CodeThink -- AT-SPI to D-Bus engineering focus right now
MM: also at CodeThink
JS: custom to create audio archive of teleconferences -- password protected by apache server; is there any objection to our recording call?
none logged
JS: use passcode use to join teleconference as passcode for audio archive
Updates, Discussion & Planning
JS: can Rob or Mark brief the group of discussion on atspi list?
Mark: gone over actual practices -- different forms between ??? and D-Bus; architectural question to be resolved: what kind of ??? to D-Bus; what are the issues encountered today, what issues can we fix; ascertain how things can fit differently into different technnologies, e.g. CORBA;
JS: appreciate opportunity to have you join us on the phone
JS: burning issues or questions?
WW: like to see people's general feeling about work that has been done -- is it worth going forward with?
MM: start is great -- surprised D-Bus twice as slow; major concern in switch is take advantage of opportunity to do revalidation; want most positive benefit out of it before done -- study life-cycle
BH: some trepedation, but opportunity to change life-cycle model if convince ourselves we can satisfy the edge if not corner cases; great work -- starting to get not just qualitative comparisons, but getting more people looking seriously at D-Bus/CORBA comparission; more eyes the better; question: is this the right move? if it is, don't have any principled objections to either COBRA or D-BUS -- don't want to take performance hit if can avoid it; if decide to keep CORBA as alternative, what would we be saddling ourselves with? majority of historical baggage could be ditched, but keep CORBA in mind
MM: stripping out baggage; i'm interested in getting rid of CORBA and moving to D-Bus -- put politics and everything else aside; CodeThink task list is fantastic; GNOME, KDE, and everyone needs to decide this is right thing to do and move ahead
RT: emailed TrollTech, dissappointed they're not representated on call
JS: is Harald Fernangle your contact? i've been pinging him; need TrollTech and KDE to be part of discussion
RT: no, not Harald -- the guy currently in charge is -- looking for it... [posted to IRC} Jan-Arve Saether
DB: let's try and get him into the discussion
RT: know their D-Bus guy very well
WW: good thing is that we are reaching out as a community; doing work in open and in public eye -- question for Michael about Microsoft's new architecture -- needs to be discussed
RT: need to move towards convergence -- immediate thing that jumps to mind is lifecycle -- ATK harmonization, feature equivalent and bridgeable
WW: discovered working with Orca API that a lot of stuff can be done under the covers --
EI: not sure 100% -- trying to read up lifecycle thread on list; ran into problem with caching early on -- need caching, but what if lifecycle short and document goes away before cached; diff shcemes may be different over the wire, but should be same for caching
MM: nice caching things in UIA -- good thing to add/map to ATK
WW: moving in that direction; in terms of lifecycle, thing most like to delete is explicit reference counting by clients
MM: yes,
GK4: timely notification when object gone or out of scope would probably solve EI's problem
EI: correct
GK4: shorter lifecycle that way; IBM interested in what others think in terms of performance penalties, how big a performance hit can we live with moving to new technology? as corallary, will implementing collections API validate our concerns? would htat make it a moot question?
WW: performance a very important issue -- timely feedback and input/output; when using FireFox to render documents with large amount of content, want to jump to elementX want to list all elementX -- not sure how collections API could help
DB: the "walking the accessibility tree" delay is in the order of seconds -- hard on user; 10 seconds bad, 20 seconds worse
BH: really expensive operations are those with schemes from collection; maybe the answer to WW's point is that would benefit all through collection -- if reduce granularity of API -- give 1 notification for state change or change in tool kit set;
GK4: let's look at 2x and see where we are -- sometimes D-Bus faster, sometimes slower -- what is overall impact on GOK, Orca, etc. -- want to ascertain net impact
Mark: net impact -- D-Bus faster in passing references; overall, D-Bus going to take a hit in order of 2 to 3 times; not sure anything D-Bus doing that is more complex than COBRA, don't know why slower -- D-Bus optimization should go on list
BH: probably get half of hit back
GK4: if want object references as flexible as COBRA ones, would lose D-Bus advantage
??: not sure how much needed -- smaller string than in COBRA
GK4: can short object references be cracked? security issue?
??: object references in D-Bus aren't hidden; in COBRA opaque; no concept of hiding reference in D-Bus
WW: think security on different layer; need priviledges to do so
GK4: network transparency only important for application instances and embedded resources - not for things at root of component -- complication in AT-SPI object can be re-parented - can't use single path to object as algorithm
??: wouldn't use object paths --
object path for D-Bus
RT: like to see an outline of the new world -- look at the proposed design
MM: absolutely right -- need to look at object references; D-Bus
RT: may be a start in questioning how works
MM: depends upon broker for events
RT: like to use D-Bus; fits quite well -- signal synchronization (one-way messages) - app registered which signals received
RT: next step is float a proposal -- lifecycle and navigation
MM: main thing at moment is lifecycle and flow control question -- very broad decisions to make; not sure what the right answer is yet
JS: who will create proposal for path for everyone to discuss?
RT: CodeThink (RT and MM)
JS: make every effort to make KDE aware of what is going on -- if anyone has alternate proposal, should address now; who other than KDE should be approached?
SB: mobile devices and mobile platforms -- D-Bus requirements for those platforms
??: need to bring in and hear their concerns
WW: anyone working for ubuntu on call? -- would be good to include them -- been active in area in last year or so
JS: not sure any ubuntu people are subscribed to open a11y lists
WW: will send JS contact info; another issue is java platform -- need path for that too
BH: java to D-Bus mapping, but java internal to AT-SPI is transparent; methods implemented 90% of code doesn't know dealing with CORBA -- no IDL code generators for D-Bus
RT: introduce components of that technology into D-Bus --
WW: help with bindings (python, etc.) transparency
??: IDL normative versus XML normative -- one is like another provided XML not bloated; XML has benefits for describing interface in lang and toolkit neutral way; as neutral if not more than CORBA; don't want to move to less concise IDL -- one good thing about CORBA is conciseness
??: need to sync with IAccessible2
JS: considered standardizing IDL as neutral
??: that was our position -- just want to be sure that XML as nice as IDL
MM: implementation detail that should be hidden to greatest extent we can
??: no problem with that -- CORBA IDL not precisely neutral
??: XML versus IDL -- ease of reading and writing; XML ease of transformation to document format
??: oxygen can parse IDL -- alot of inline documentation in IDL
??: oxygen doesn't handle IDL at lower level of granularity -- could use XSLT to transform into "pretty" pages or docbook
??: surprised -- oxygen plus IDL
??: really don't like
??: no advantage one way or another
GK4: machine parseable format that is easy to read?
MM: yes, machine parseable, easy to read
??: IDL has to be machine parseable
MM: true, depends upon what parses it
??: can live with machine parseable as long as can still read interface definitions
??: if go to XML has to be something readable, not a hyper-customized dialect; working on examples -- will post to emailing list
MM: implementation details -- use D-Bus can lay stuff ontop of raw interface to deal with caching issues and document IDL in detail
BH: nice not to be tied into single mechanism
MM: UIA gets this right -- AT-SPI black box
??: depends upon how UIA works -- defining an interface or way for apps to talk to one another?
??: shouldn't be writing in D-Bus XML
MM: but not standardized --
??: XML and XML-derived languages can create new bindings to write interpreter/compiler for interface -- theoretically great strangth of COBRA -- should retain so can point people in future to an IDL
MM: java doesn't do that; phython wraps COBRA; we've wrapped in C
??: java had pre-existing a11y API -- part of building java is running java IDL compiler
MM: bridge piece needs to be easier
??: can swap out glue, but when add new language, going to have to add new bindings
??: relatively straightforward -- have to be library applying to
MM: sharing is the pain
JS: what is elegant is a protocol that, in theory, has IDL compilers for target languages to create language-appropriate bindings, but at end, diff languages would perceive as objects --
??: pycorba nice for this -- model can be extended for future languages -- hope for D-Bus, right?
JS: want a standardized interface description, just not sure of details
EI?: thought didn't want standardized until get to AT level
???: the "I" in HCI
JS: need to return to this issue -- can we briefly speak about implications of testing in LSB moving towards D-Bus -- does it change anything substantively? libatk in LSB -- working on LSB perfomance tests to ensure AT will receive useable info to transmit to user; ATK/AT-SPI layer -- does that change anything?
GK4: not sure -- pyatspi?
??: dozen tests of ATK in C -- russian academy of science has over 200 test cases for ATK -- don't know if just calling API that exists or what
??: what method are they using?
??: have to investigate -- think a lot of COBRA code
MM: no conceptual difficulty if atspi-based -- if going from COBRA to D-Bus, may be a good test to ascertain if D-Bus successful
GK4: agree
JS: just past the hour -- thank everyone for participation -- any last thoughts?
New Business
- availability of participants for calls for remainder of December 2007 and beginning of January 2008? extremely limited
- the next Open A11y Workgroup conference call will be held on 8 January 2008
Identify Topics for the 8 January 2008 Open A11y Teleconference
CG: are you going to go through topics for next meeting? could present UIA work and our intentions vis a vis Open A11y -- go through what we are planning
JS: next vcall 8 January 2008 --
CG: can we address some issues with IA2 as well at that time?
JS: yes -- Pete Brunet of IBM, and chair of IAccessible2 workgroup at Open A11y, will resume his usual active participation in January 2008
RESOLVED: The next meeting of the Open A11y Working Group will be held on 8 January 2008
JS: if need to add additional calls can schedule subteams to meet at separate times -- whatever moves agenda forward
WW: bursting to say -- big thank you to the Mozilla Foundation for their funding and especially Rob and Mark for their professionalism and their willingness to share so openly
Wrap Up
Summary of New Action Items
Summary of Continued Action Items
- ACTION GJR: mock up template for Open Accessibility specifications by 15 January 2008
- status: in progress; continued
Summary of Resolutions
- Minutes from 4 December 2007 Open A11y Call approved without objection
- The next meeting of the Open A11y Working Group will be held on 8 January 2008.
- meeting adjourned: 3:06 PM EST/2006h UTC
- next Open A11y meeting: 8 January 2008