From The Linux Foundation
Jump to: navigation, search

GJR's ToDo List for Accessibility/Minutes

September 2007

  1. done: flipped chronological order of table -- from oldest to newest to newest to oldest (9/11/2007)
  2. next step: replace wikified table with HTML4.1/XHTML1 table with headers/id bindings and scope

note: the following pre-dated GJR's assumption of webmaster duties; before i delete it, i need to check if this is what is replicated in either:

(Actual) 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 services 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.

Bill- we are asking to do something different, I understand the guaranty. We need to see how within if not LSB, within FSG process to do it.

Jeff- maybe all the implementations are Python so the ABI worry might not be that big in practice. Maybe applications rarely are exposed to the ABI. So maybe it is a theoretical problem and not a practical one. We are not saying it is not going to work, we are just voicing our concern. We have to make sure we are preserving the brand promise.

Ian- This gets back to something I said before, it sounds like we have a good story from the viewpoint of a typical application that just wants to be accessibility enabled. Use atk or use qt4. What I am concerned about is the other side of that equation, the applications that provide the access services. It sounds like they are all open source up to this point. I am wondering if we can make a less strong guaranty for a class of applications that can be delivered on an LSB platform, while allowing other applications to have the more robust LSB guaranty. If I am an ISB that develops software that has accessibility features, what kind of guaranty am I going to get from the LSB that my application is going to run in the future?

Olaf- There are 3 sides to the conformance testing, one is about the applications that are meant to be accessible, there we don’t have a problem. The second is the assistive technology, there the message is here is an ABI which you can use. It might be necessary to provide an update later for distributions that provide a different ABI using the same API.

Janina- when would we get rid of the ABI, when would we deprecate it, under what circumstances?

Jeff- you mean the current CORBA based ABI?

Janina- yes, if we standardize on that but in some point in the future introduce a new ABI. At what point do we decide if there is a problem keeping both?

David- from an OS vendor distribution point of view, there would be a problem having to continue to shift the CORBA implementation and the dependencies that would involve. A lot of OS vendors wouldn’t like to do that, at the same time they would like to have the LSB but it would be difficult for them. There would be the risk that the LSB would loose some value .

Jeff- would it be possible to write a wrapper API to abstract for the differences between CORBA and D-Bus so that we could provide a stable ABI across that barrier?

David- I am not aware if that is possible but it is something someone could investigate. The proposal includes the IDL files so the CORBA standard defines what to do with them. It is a pretty difficult process ..

Bill- as an aside, the same IDL syntax has been used by other protocols beside CORBA. Whereas OMG’s CORBA specs define a very specific ABI for each official language which results when you implement IDL In other words, OMB tells you what exactly what ABI you must use in order to implement IDL using CORBA. It is possible to implement IDL using some other technology to some other ABI. That is what we hope to do.

Janina- there is the expectation the we will get rid of the IDL; that is going to be normative, right?

David- I would be able to take the IDL, I could write an application that uses some CORBA implementation. That would still interoperate with the CORBA implementation provided by the LSB compliant platform. Which means that the LSB compliant platform, in order to provide these services, would need to include a full COBRA environment as specified by the OMG.

Bill- could you restate that, I’m not clear where you started on that last bit?

David- O.K., suppose the LSB includes these IDL files. Then there is an implicit guaranty that this is a CORBA run time environment on the system.

Bill- no, I don’t think so.

David- if not such a guaranty, how are the IDL then useful to applications so that they do not have to be recompiled?

Bill- what we mean by making them normative is to say that the IDL files define the interfaces but not the binary interfaces. They enumerate the services provided and characterize them. I agree that does not give you enough to build an application. But in combination with at least one ABI, you can build an application.

David- true

Bill- If the ABI changes but the IDL does not, porting the application might actually be trivial. The way that IDL does work in CORBA, there is a mapping between IDL syntax and a particular protocol. You can define a different mapping to another protocol. That mapping will give you slightly different bindings in different languages but they are very closely related to one another. So it is kind of a pre-processor job.

Janina- and that is the proposal, the IDL stays, just a new ABI appears at some point in the future.

Bill-the purpose of that from the point of view of standardize is to give some structure to the claim that future conforming ABI’s will be feature equivalent to the current one.

David- in order for the IDL to be useful, I should be able to write a program and provide a binary that uses some kind of CORBA environment as defined by the OMG. No matter what language I write it in or what CORBA library it uses, there needs to be some kind of environment that conforms to CORBA.

Bill- that is if your understanding of IDL it that it is specifically CORBA IDL.

David- looking at the IDL files proposed, isn’t that the case?

Bill- no, that is not really what we are proposing.

Jeff- would it be possible to ship a more traditional dynamic library based on the CORBA ABI and use that as a shim layer that would be translated to use the later ABI? The problem is that library would have to be shipped by the distributions.

Bill- you could do it but it would be a pretty ugly and Baroque thing. If you succeeded in doing it you what have succeeded in re-implementing CORBA. You would have written an alternate back end for CORBA which is not what I think we want to do.

Jeff- no, I don’t think so

Bill- couple of observations. One, as a reality check, it is true that the CORBA dependencies that would be incurred by a platform would not be that large. Only, in the case of current distributions, ORBIT2 and Link.

David- Bonobo.

Bill- Bonobo is another thing. Most of Bonobo can be eliminated.

David- sure, that is not the point today, just looking at the IDL

Bill- it is the point. You are talking about big dependencies for CORBA. But let us leave Bonobo out because it really is a red herring here. The only thing being used in the IDL from Bonobo are 3 methods from Bonobo_unknown.idl, it is a 3 method class.

David-and Bonobo_stream, I think.

Bill- we have deprecated Bonobo_stream so we would not want to put that in our validation suite. So Bonobo is out of the picture, it is really just ORBIT2. It is not a big chunk of library but there are some who are saying that in some imbedded systems it could be a problem. I am not arguing that is not significant in some environments. But it is not a very big dependency as libraries go.

David- I agree that ORBIT2 is a small CORBA implementation and it is one that every distribution ships today. And it is okay for most distributions to continue to do that. But from a distribution point of view, if LSB says these are the IDLs and you need ORBIT2 then it is very hard for distributions to be LSB compliant and migrate to using D-Bus latter on. If there was a D-Bus interface later, it would mean that distributions would have to ship ORBIT and D-Bus and that is not desirable for an operating system vendor. That is my main concern.

Jeff- the main problem for the distribution, shipping something just to meet a spec, the question is who is using this. If the answer is no one, we just ship this because the LSB says we have to, that is a wasted argument.

Bill- we prefer not to do it. It is just 30k of code, possibly more.

Jeff- it isn’t the size that is an issue, it is the maintenance burden and the testing.

David- security issues and all the concerns on shipping more than one.

Bill- there is hope that a drop in replacement for some language is possible. [1:01]

(to be continued)