AT-SPI: Outcome of Discussions

at-spi IDL is primary to our spec (foundation API)

review IDL to make sure all should be included in 0.1

conformance and validation requires ABI component(s)
clients require client-binding consistency
functional requirements/interoperability require protocol standardization
we wish to separate protocol from client ABIs because there is value in allowing additional protocols in the future

must make this explicit
must ensure that adopters and clients understand the nature of the protocol conformance guarantees

lightweight process for adding protocols, i.e. don't want for '2.0'
should begin to define acceptance criteria for new protocols, and submission process

should define back-compatibility and interoperability criteria
acceptance criteria will need to reach up to bridge/server side, to ensure full functional compatibility with existing architecture and 'legacy' GAP

1.0 will include IDL, a set of 'blessed' client bindings, and existing CORBA protocol

reason for blessing specific client bindings is to aid in new protocol acceptance criteria
the 'blessed' C binding might be cspi instead of CORBA_C bindings, because of the broad exposure of CORBA in the CORBA-compliant ORBit2 C bindings.

       * note that this initial spec already allows writing AT without any explicit GNOME
          dependencies other than glib (because CSPI is plain ANSI C).
          [there may be a trivial pango dependency here as well]

Actions

Review IDL for inclusion
Identify 'problem' dependencies
Identify which problem dependencies might be excised
-> e.g. libbonobo/Bonobo, cspi->libspi.so
Assign resources to excise/refactor code to encapsulate or
remove those dependencies
Start making regular contact with the FSG desktop group, in context of
their discussion of ATK standardization on application side.

Issues (also actions - to investigate and discuss further)

investigate implications of changes to AT-SPI activation, ref-counting, and dependency triage on GNOME ABI stability guarantees
we appear to be left without an activation ABI/API for 0.1
what testing harnesses/technologies should we use? How much do we care about the dependencies of our validation test binaries?