To compile, run "./configure", then "make".

This is still alpha, but should work fairly well.

The IO subsystem's greatly improved.  It's basically split into two
pieces, the way libtiff does things - you can either use acap_Open()
and give it a server name and it'll do all the work, or you can use
acap_OpenConnection(), supplying the routines for the library to use
for IO; in this case, the acap_Open() code won't even be linked in.
It's slightly trickier, but it's easy to integrate it into anything.

The parsing module's still a bit ugly, but for lack of a decent lexer
or parser generator, it's not going to get any better.

The API's been changed a bit.  I think the current version's fairly
useable - comments and suggestions would be much appreciated (I know
it's a little tricky to understand, and that the constructors
eliminate typechecking; nevertheless, I've yet to hear of a better
system).

That being said: it's likely to change a little more (commands that
take varargs lists of strings may be changed to take arrays of strings
instead...)

There's still no documentation outside of the header file and the
source code.  This is regarded as a bug.

It's also still not as portable as I'd like; it should compile on any
modern OS, but may have problems with older (especially non-ANSI)
systems.  (The only non-ANSI thing it uses is alloca(), and the socket
routines in acap_Open()).

It should be fairly easy to port to non-Unix systems.  All of the
interesting system-dependant code is isolated in open.c (acap_Open()
does a lot of work for the library user, but setting up sockets and IO
tends to be highly system-dependant).  Alternatively, if a library
user doesn't want to use the acap_Open() interface, and instead uses
acap_OpenConnection(), no porting should be necessary at all.

  )Rob Earhart
   Carnegie Mellon University
