MD: We have two tests in LSB testsuite. First in desktop-t2c, developed by the guy sin Russia, medium-quality (API compatibility and functional tests). Also something started by George Kraft and people at IBM, mentioned in last meeting. More of an AT-SPI test using cspi. Desktop-t2c tests have full coverage of ATK interface. IBM tests are just a start: has a framework. Desktop-t2c tests not as useful as perhaps other medium-quality tests since ATK needs an implementation and there is a dummy implementation. Recommends possibly modifying the tests to use gail implementation of ATK, but more useful even than that would be to add AT-SPI tests to LSB rather tha nconcentrating on ATK. Not sure how direct usage ATK would get; most people will go through AT-SPI, so this might be the better interface to look at. Perhaps do shallow tests for cspi and more comprehensive tests for pyatspi.
SB: As we're moving up the stack with LSB, we're seeing this type of thing more and more. The traditional LSB testing model was to test that interfaces exist, behave correctly when passed a valid or invalid set of arguments, not relaly doing the pipeline set of things. Running into the same issu ewith cups; can't test the library w/o a printer and daemon. Needed to use a daemon and a dummy printer.
MD: ATK has a standard implementation (gail)
WW: Testing ATK is one thing; those tests are valid and should exist. Assistive technology is another issue; can it get the info it needs? We're also looking at kde coming into the game. I predict that oject hierarchies, event orders, event types will be different between qt and gtk. If we write tests based on AT-SPI, pretending that we're an AT, may need a different set of tests for gtk vs. qt apps
MD: LSB would need tests for both qt and gtk. Would hope that most tests would remain the same.
SB?: If we create a testsuite, do we write a sample app? We could write an app that will talk to ATK directly, creating dummy objects. If we use a real-world toolkit, we'll have separate tests for qt and gtk.
MD: That should happen for functional AT-SPI testing; need separate tests for gtk and qt.
WW?: Ideally we only need one AT module for both toolkits
MD: Have a bunch of applications with one or two interfaces
OS: QT has a plugin architecure; can plug in equivalents to ATK. Already have some dbus-based stuff in there, very close to ATK but not really close enough. The move to dbus includes an effort to work on the qt side as well. Kde will use the internal qt interfaces so that stuff ends up on the same dbus accessibility layer. Will not use ATK but will use the dbus bindings.
WW?: Leaves other ATK implementations: Mozilla and OpenOffice
CG: Had Brian come on the call because he is heading up UIA testing. We'll have our own binding. We're planning on writing winforms apps and may be able to model them similar to these others and plug into whatever framework is there.
MD: In summary, there are a few ATK implementations (mozilla, gail, UIA)
MG: There is also the Java access bridge, which binds directly to AT-SPI, not ATK
PB?: Trying to add a jmi(?) layer for Java
MD: How far do we want to go with ATK testing, as opposed with something new and large, testing AT-SPI?
JS: for purposes of standardizing. If we get this right, our tests become what is needed to pass for LSB certification
PB?: Testing through AT-SPI is probably the better thing to do, since we need to ensure that ATs can operate
MD: If LSB standardizes pyatspi or perhaps cspi, then that fits in with what we're doing more
JS: Is there an objection to standardizing based on AT-SPI?
OS?: If we wish to test an app, we would only test on the AT-SPI level, and tests would heavily depend on which system you performed the investigation on. Important to test AT-SPI at the application level because it fits into the real world.
SB: This goes beyond what we normally do for app testing. For LSB, we're probing an application for what libraries it's using and testing that an app runs. Does this include libspi and libcspi?
MD: libspi is being replaced, but we're hoping to keep the cspi and pyatspi client interfaces the same
SB: Ideally, if libcspi was required, it should be included in LSB?
MD: MG started working on cspi. If we have tests, then they should still run when moved to dbus
SB: We're looking to retain compatibility with SLES 10 and RHEL 5. Dbus is still lagging on these platforms, something below 1.0, so dbus isn't in the tests.
MD: cspi would not go in, at least the dbus version. There would be some breakage.
SB: If something goes in as a trial use module, can bypass that gatekeeping. We use that as an indicator of where folks are headed. If we put this in LSB, how widespread is it? We're still collecting test data; doesn't affect anybody'[s certification. Just gives us feedback on how widespread this really is.
JS: Timeframe for LSB4?
SB: End of this year.
JS: Even if we were extremely fast at generating this, most that would make sense would be trial.
SB: Management would really like to see everything done by the tail end of August and spend remaining time fixing issues that come up, since we slipped for 3.2
JS: Probably too optimistic of a timeframe for us
SB: Once 4 is out the door, we're looking at a SLES 11 / RHEL 6 gatekeeper. May have more things available.
JS: Should bring us closer. Not sure what will be in RHEL 6. Will probably look a lot like Fedora 9
DB: How maleable are the LSB standards?
JS: Maybe Stew can say better. By the time you make tests required in LSB, you don't want them to change very quickly. Going in via trial probably makes sense; gives people the opportunity to adjust and give feedback while it's still not mandatory.
SB: Once an interface goes in, if we decide to deprecate it, we'll hold it in for that long (6 years?) If an app uses it and it's deprecated, it will come through as a warning. The testsuites are always under a continual state of improvement.
WW?: If we keep going on the path of harmonizing ia2 and AT-SPI, what impact does that have on standardization efforts for AT-SPI?
SB: You're adding new interfaces to an existing library? That shouldn't be a problem. An app that was 3.2-compliant and didn't have the interface couldn't certify as 4.0.
WW?: What about incompatible changes to the API?
SB: We'd rather not see that at all. When putting a library into LSB, it's part of the promise that the library is stable.
WW?: Standardizing is a good thing, but it also puts the handcuffs on. We should make sure it's the right thing before we standardize it. I'm not trying to put the brakes on here, either.
JS: Next steps? Should talk about it next week as a primary topic. Want to move this in a direction where we have a grant proposal.
MD: Should continue the discussion on the accessibility mailing list. I could put a more detailed proposal together depending on how people feel.
JS: mechanism to check in with Calvin's group. Should we make an agenda item to talk about it on a monthly basis? What's a good way to do this?
CG: We publish our schedule and where we're at, but that's a lot for people to digest. As far as ATK, perhaps the best way is to bring it up once a month. We have a lot of discussion on our own irc channel. We're writing dual unit tests: we test our implementation on top of ATK (ie, a push-button); we have a gail test and then run the same exact test on our implementation. I don't know if this is th eforum to talk about this stuff other than to give updates. If we run into serious issues, I'm going to bring those up here anyway. I don't know the best way to do this.
MD?: Would be happy with a monthly update, a 5-minute chat
CG: I'd be happy to do that. May have different people come on as well (had Brian come on today), just so you don't hear me every single month
JS: Sounds good. Shall we make it the first meeting of the month? If isues that arise that need more attention, then we can also take that up, as an agenda item or as a separate conference
PB: Should be another week. Haven't talked to Gregory in a couple weeks; need to talk some things over (html-strict).
JS: We're still on track to announce a last-call rfc next week. Will close that at the end of June. Still up in the air if we're going to continue to ISO, but those are necessary steps either way.