On Wed, May 28, 2003 at 12:03:32PM -0700, Erik E. Fair wrote:
> CAPI = ?

[Sorry, it didn't occur to me that this is probably unknown in non ISDN-happy
countries, so here is a bit of background info]

As Andre Nicklas already explained it's an API for userland programs to
access ISDN services (wich in our case are implemented mostly in kernel and
in small parts by isdnd).

It is pretty feature full, and thus carries some complexity.

Our native ISDN API, on the other hand, is very much simpler and restrictive-
one could actually say lacking some features. It works fine with dumb cards
and applications like "answering machine" and "connect me to my ISP via ppp".
It does not realy extend to the level where you could build a ISDN conference
system, a fax machine, or what have you.

There are some ISDN cards that already implement CAPI nearly completely on
their own processor and basicaly use it as the interface to the kernel
driver [*]. The code Antti ported makes the CAPI interface available to
userland on such cards and plugs into our native in-kernel API. This gives you
userland API support on this (expensive) cards while not burdening the kernel
part to implement CAPI on dumb ones.

Doing a partial CAPI implementation as extension (or replacing) our native
interface would not be very hard (depending on the value of "partial" of
course). But there has not been many demand in this direction (that I know
of).

Martin

[*] = the historic reason behind this design is kind of funny nowadays:
CAPI had one of the first bindings and deployment as a DOS driver (TSR,
if you remember this). Typical implementations for dumb cards took ~120 kB
out of the 640 kB available RAM. This was not acceptable. So a bit more
power was put on the card itself, and the DOS driver shrunk to a small stub
(a few kB). But now the card had to basically speak CAPI all by itself.