Re: Accessibility module loading

[Michael Meeks <michael ximian com>]

Hi Padraig,

On Fri, 14 Dec 2001, Padraig O'Briain wrote:
> I take the view that accessibility support should not be an add-on but
> the accessibility support for a widget should be in the same library
> as the widget.

	I personaly think this is a mistake, I am not convinced that the
(huge: a new API per new widget in Gnome ultimately) gail API should be
frozen and exposed to the public.

	I have a growing convinction that we need to be able to expand and
modify the gail APIs in future - and of course, this we cannot do if every
core Gnome library is using them.

	This contrasts with the proposal I have put forward, which would
allow gail's modules to be demand loaded - and accessibility support for
the gnome platform to be implemented inside a limited number of purely
accessibility related modules - thus splitting the dependency tree and
minimizing any Accessibility API impact.

	Given that it will have a relatively minimal performance impact -
I can see virtualy no disadvantages to bifurcating the dependency tree and
pulling a new, massive, untested API out from the bottom of the pile. eg.
it is not really reasonable to make libgnomeui depend on gail IMHO. It
would be ideal to keep this API private.

	So - here is what I suggest.

	We guard all the installed gail headers with:

#ifdef GAIL_PRIVATE_API_DONTUSE
#endif

	And since people want to leave gail at the bottom of the build
dependency stack [ fair enough ], we create another module say
'gail-gnome' higher the build dependency stack [ that depends on
libgnomeui, eel, etc. ] and that installs:

	libeel-a11y.so
	libgnomeui-a11y.so

	etc. and we dynamicaly link them in automaticaly via the proposed
hooks.

	This has the advantage that the gail API is a shared, private
contract between 'gail' and 'gail-gnome' and thus it can be altered
substantialy affecting only two packages. Clearly in the future when we
are 100% happy with exposing that volume of API - and it has been well
tested and shaken down it makes sense to expose gail to everyone.

> If we took this view the only thing we would lose is the ability to
> dynamically change accessibility support.

	We will still need this; since there will be a performance impact
(however minor) to accessibility support - and we don't want to push that
on all our unimpaired users IMHO.

	Does that explain the rational some more ? I would be rather
disturbed if you were to unexpectedly come out with the expectation that
libbonoboui, libgnomeui etc. were intended to depend on gail in the build
order.

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot