Documentation

We are working on detailed documentation. Meanwhile, here are a few hints to get you started:

• eCAP is the interface between the host application such as a proxy server and an adapter module that implements some content analysis or adaptation (including logging, filtering, blocking, injecting, translating, decoding, or encoding). The host does not know adapter details and vice versa. The two communicate via standard eCAP interfaces.

• The libecap library available on this site implements eCAP API in C++. We also provide sample adapter implementations that use the library.

• Both the host application and the adapter module should link against the installed libecap library.

• The library itself has little "real code". Its focus is on declaring the interfaces that host and adapter software must implement to work with each other.

• If you add eCAP support to a host application, you need to implement the host::Host and host::Xaction interfaces as well as MIME-like Message wrappers. In general, implementing host support is more difficult than writing specific adapters. Fortunately, there are fewer host applications than needed adapters. Currently, eCAP support is being added to Squid proxy cache and Spicer ICAP server.

• If you are writing an eCAP adapter, you need to implement the adapter::Service and adapter::Xaction interfaces. The basics are straightforward and working samples are available. Once the required interfaces are supported, you can focus on the specifics of the adaptation service(s) provided by your adapter. Your module will work with any eCAP-enabled application.

• You can download the library, compile, and install it the same way you handle most open source packages on a Unix-like system.

Upcoming changes

While the overall libecap design is not expected to change drastically, API and source code changes will happen as we gain more experience with real-world eCAP deployment. For the first few development releases, you may have to rewrite, hopefully small, portions of your code to stay in sync with the changes.

Here are some of the short-term improvements we work on with completed items crossed out:

• ServiceConfig class to pass configuration information to the adapter.

• Ability to create new messages from scratch, without cloning virgin messages.

• Host-assisted blocking of messages.

• Meta-information exchange between host and adapter transactions, similar to ICAP headers.

• Migration of headers related to message structure to libecap/message or libecap/mime.
• Safer Xaction pointers using shared_ptr.
• Support for threaded adapters.
• Browsable documentation.