From The Linux Foundation
Jump to: navigation, search

Accessibility Minutes November 1, 2006


Olaf Schmidt

Gunnar Schmidt

Bill Haneman

Jeff McQuia

David Sutton

Janina Sajka

George Kraft

Ian Murdock

Old Business

Minutes: Will defer discussion of August minutes until next week. Minutes for 18 October approved. Minutes for 25 October approved.

Ian- there are a few things on the old legacy servers including the accessibility non-wiki website and version control; how much longer are we going to need to keep those up?

Janina- we wanted to be familiar with the process while completing the Keyboard I/O specification to make it easy for Bill to update the test assertions on CVS with which he is familiar rather than a new system. On the website content, there were questions on accessibility.

Ian-keeping the system running isn’t a problem, I just wanted to give the System Manager an idea of how long to keep it running. If it is January, that isn’t a problem. Janina- we were making progress on the spec.

Ian- we can take that up offline.

George- I have moved the majority of the php pages to the wiki system. I asked for people to see if there was anything that was missing. We should be able to move to the wiki as our default website. I think everything has been moved; the minutes are there, the charter, and resource links are there.

Ian- there were some things that were in the version control that were being automatically checked as part of the http namespace and we can work with you to make sure those are working on the new server.

George- I will copy the CVS server to BVR and then check that out on the web to see how to use that.

Ian- Jeff McQuia is the person to talk to about that mechanism for doing that. Check with him offline.

Bill- George, did you receive the latest version of the keyboard spec?

George- not sure, please resend it.

New Business

Janina- Bill, please take us through the review of the spec.

Bill- I’d like to ask Ian first if there are any questions about the document we circulated. Ian- No, it looks good to me. From our perspective, there are only a couple of prerequisites for getting in to the LSB. It must be present in the major Linux distributions and I believe that is the case here. The other is that there must be people willing to do the work and that is the case here also. As long as you have answered these basic candidate questions, we can help you get the specifications and tests in the proper framework so that we can integrate them. I asked Jeff to call in because he can get a little deeper than that.

Jeff- I have one major question about which ABI that would be specified in the LSB, at least in the initial run. I am familiar with the problem of CORBA vs. D-Bus and I agree with the assessment in the document. The LSB is trying to promote ABI stability. If we tell people in the LSB to use a certain ABI, we want to give some assurance that it not going to go away. We will need a little more detail on how that is going to be managed would be useful.

Bill- That is crux of the problem. Backing up, with respect to the requirement that the technology be present in the major distributions. We have that for our CORBA based ABI. From there we can move forward with the conformance tests and standardization. We do not want to move forward with a long term ABI compatibility guaranty on that. We don’t want to make all compliant platforms to provide that ABI in perpetuity. We want allow for the option of an alternate ABI but that ABI does not exist yet. We want to make sure that by putting one ABI in, we have a way of signaling our intentions and making sure that we do not infer a stability guaranty that - not so much a stability guaranty, we are not proposing the ABI will itself be destabilized but what we don’t want to do is guaranty that that ABI will always be the one that is conformance tested as present. It is not that the ABI will break, but the ABI might be entirely replaced for an alternate conforming ABI. We want to make a slightly different kind of guaranty, a weaker guaranty that is normally make with LSB.

Jeff- is the ABI that exists in the distributions, is that atk?

Bill-AT/API, not atk. we have a layered architecture, the ABI called atk is something that is going to be around and tends to accompany gtk. It should be discussed with gtk and the LSB role of gtk and associated technologies. The problem is that the nature of this ABI is different. It is only useful to clients if the majority of the applications on the desktop are using it.

Jeff- if I understand the objection to atk is that it is gtk specific and we are locking the KDE people out?

Bill- no, atk is a different thing, we should probably take atk out of the discussion. We need to discuss AT/SPI, atk is at another layer in the architecture and we do not have a problem with the any of the plans for standardization path for atk. Atk doesn’t help the assistive technologies because they don’t talk to it directly. Atk is for application writers. From the viewpoint of people asking the question- will my assistive technology work on this platform - they need to know the ABI they are familiar with is going to be there. But more important, the need to know that the applications running on the desktop and the desktop infrastructure is going to be providing a particular set of service ABIs. That is where it gets tricky. There is a difficulty for the KDE with providing the current set of service ABI because of their dependency chain. The technology isn’t loved particularly by anyone but it just happens to be solving our problem at the moment. It maybe very useful none the less if we can guaranty that some ABI with a particular set of characteristics is present on the system. We are making an API guaranty and saying an ABI which - an ABI whose details will be documented and will be available on the conforming platform and the ABI will implement a well known API that is known to all the clients.

Jeff- I see

Bill- It does not mean that your assistive technology is guaranteed to work drop in, out of the box. But it does mean the it can be ported from one ABI to the other relatively easily.

David- I think there are some concerns from distributors like Fedora, if the LSB would include AT/SPI, it would be difficult to move to a new version that doesn’t use COBRA as the APC.

Bill- that is right. That is a good point. The difficulty is not just with KDE. If we could come up with an alternative in Gnome as well and preferably an alternative that all desktops could share. We don’t want to have an obstacle to moving to improved technologies.

Jeff- good point, even though the technology may be best practice today and ubiquitous, there is some advantage to understanding which best practices are on there way out. We are trying to put a long term binary compatibility guaranty in place at the LSB. By putting something in the LSB we are saying that this ABI is going to around a long time. Redhat does something similar, they are careful to articulate which parts of the ABI are stable and which are not. It is roughly equivalent to the LSB vs. non-LSB. If you don’t want to enshrine the ABI in the long term, It sounds like there is general agreement that we want to move to a different ABI but that ABI does not exist yet and certainly is not widely adopted. Maybe the best thing to do is to include the current AT/SPI standard as what we call an LSB optional model. It will provide some guidance to application developers from an API point of view about what is coming. Then postpone folding AT/SPI into the LSB proper until LSB 4.0 when we will have a better idea about what the ABI will like.

Bill- the alternate ABI may not be that quick in coming. We need to make sure there is sufficient motivation to provide it. I would be concerned about delaying. As we said it is already in the major distributions. We have an important value to aid by moving forward with the standardization process. Rather than make it an option module, it would be better to move forward with the current module and standardize on the API. That is our proposal, to standardize on an API and guaranty that a particular set of services will be available on conforming platforms. We will have conformance modules that explain what it means to provide that service, i.e. at least one set of ABIs that conform.

Jeff- what kind of message you would have to a software vendor, say I am Real and I am producing an LSB compliant binary with accessibility support. When a new ABI becomes standardized, what message should LSB be giving about the previous binaries?

Bill- As far as I can tell, the software vendor would not be touched by this ABI spec. at all. Right now we have nothing to say about application space. When we say client, we mean assistive technology. The only apps impacted are assistive technologies. This is one of the weaknesses we want to get around. We want to get to a point where in a conforming desktop, there might be a statement about the accessibility support about a conforming platform. Right now all LSB is saying is that a set libraries are available to an application. From an assistive technology standpoint it does not tell you very much. It gives you no indication of whether those services are active.

Jeff- what you are saying is this is not a spec that Real would be concerned about. It is for someone who wants to use Real player with assistive technology. Is that correct?

Bill- yes. It lets users know that particular assistive technologies will work on the conformant platform. It does not guaranty that assistive technology will work with a particular application.

David- if Real player is LSB 3.2 compliant and the accessibility standard is part of LSB 3.2, when the ABI changes in a new version of LSB, will the LSB 3.2 compliant Real player binary work on the new platform?

Bill- almost certainly, it is unlikely that the Real player will use the ABI at all.

Gunnar- I would say that it depends, if Real uses atk, then the Real player would not have to be changed at all. If they implement the AT/SPI directly, they would need at least recompile.

Bill- yes, but we’re not aware of any application that uses AT/SPI directly.

Gunnar- in LSB we already have atk and qt4 modules. Once we have a solution for KDE, all applications that code to qt4 API and implement accessibility will work with every solution KDE uses. The same for any gtk applications or application that uses atk.

Bill- in practice the applications tend to write to a set of stable APIs. The assistive technologies use at the moment AT/SPI and the ABI may change but the interfaces and services will remain the same so it is a straight forward port. We anticipate that some of the ABIs will be the same in certain languages. So the AT/SPI ABI as we know it is a set of bridge code that gets tends to get swapped out with platforms. If you upgrade your platform, you upgrade this.

David- is there a market place of software that works with other end of the AT/SPI pipeline? You said the software would guaranty that a particular set of services would be provided. Which I imaging a distro would provide with a specific software. When the ABI for AT/SPI changes, what will the distro impact be. What will be required of the distro’s to produce a product conforming to the new API, what compatibility guarantees are going to break, etc.

Bill- we want to allow one of 3 scenarios. Either the Distro will stay with the old ABI, Distro can switch totally to the new ABI or Distro can support both. We wanted a solution where all three would be possible.

David- in theory, from an application point of view this would be transparent because they use either atk or qt4 and those libraries would hide the changes AT/SPI.

Bill- yes, as it stands the connection between atk and AT/SPI is provided by bridging code that is part of the platform. The platform can be change the bridging software at any time and the applications would not be aware of it. In fact, when a change like that takes place, it will take some patching, bug fixing and QA but in terms of the ABI the application sees, there is no change, applications continue to speak their native accessibility protocols.

David- are the service provided for assistive technology provided by the distributions or are they something that might be an add on?

Bill- they are part of the platform.

David- if the AT/SPI ABI changes, then it is really a problem for the distributions.

Bill- it is a problem for the distributions and the AT clients that use those services.

(to be continued)