[Kde-accessibility] Diagram of our approach

[Bill Haneman]

On Tue, 2002-12-03 at 18:56, Olaf Jan Schmidt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi!
> 
> I have made a diagram of the approach we decided to go with.

Thanks Olaf, the approach looks good.

> Bill, is there a name for the AT client library?

I have some questions about the diagram, related to this question.  

I think the diagram might be a little confusing since it talks both
about 'libraries' and is also a 'block diagram'.  This can lead to
confusion since a single block in the diagram can consist of multiple
'libraries', but of course libraries are often used by more than one
'block'.  So I would separate these out, and not talk about the actual
libraries in the block diagram.  I think having the block diagram refer
to components and APIs instead would be clearer.

The AT-client has two available APIs; a CORBA API (which is available
for all languages which have defined CORBA bindings, i.e. C, C++, Java,
etc.) and an optional "wrapper" binding.  We have a simple C wrapper
which provides an API we call "cspi".  It's not a bridge in the sense
that other components are bridges.

You are right, gnopernicus and gok both use the cspi wrappers now, but
we do have demonstration Java AT clients that go direct to CORBA, and
one of our members also has developed a pure CORBA C client.  So I would
not make the AT client libs module central to the client side of the
diagram, I would just label that side 'AT-SPI (CORBA)' and indicate that
clients may use the 'cspi' wrappers or not.

Also the arrows from ATK to AT-SPI are a little odd in this context,
since they omit mention of the actual bridge component.  If you want to
leave the diagram this way (i.e make the bridges "implicit" in the
arrows) then I would definitely change the "AT client library" block to
read "AT client(s)" and show that the client can optionally use a
wrapper API here as well.  If the client doesn't use a wrapper API then
it doesn't have to link to any of the accessibility libraries; in this
case it just provides client CORBA stubs.  I wouldn't necessarily
mention the 'CORBA stub library' in the diagram since these stubs are
automatically generated and would be assumed to be present by someone
familiar with CORBA.  (Just indicating that a client uses CORBA implies
the presence of a client stub library, and there's no need to mention
that library just as one usually doesn't mention "stdlib" or "libc" in a
diagram.)
 
Perhaps we should chat on IRC about this one more time, to clarify what
your intent is regarding the client side of the diagram. Would that be
OK?

regards,

Bill

> And Pupeno, could you have a look at it whether everything else is OK?
> I will put it onto http://accessibility.kde.org/developers once everything 
> is OK.
> 
> Olaf.
> 
> - -- 
> Olaf Jan Schmidt, KDE Accessibility Project
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iEYEARECAAYFAj3s/loACgkQoLYC8AehV8dJLACeNgvSdlPfP7SJHSQYwosCSeaP
> TRIAoLiKm8dOmQvg0n6hq2H1+IlwNFCa
> =GIK6
> -----END PGP SIGNATURE-----