V4 Server Side Plugins

This page is being used to develop a design for server side plugins, i.e. generic modules (code running on the IOC) that can be plugged between the EPICS database and the CA server libraries to provide additional functionality to database records in a generic way.

aka Circular Buffy, the Vampire Layer

---

General Design Ideas and Guidelines

DA Extension/Override

The plugin can interpose a DA interface - replacing the original DA interface provided by the EPICS database - to be able to add properties to a record's property catalog or replace existing categories. The plugin itself is then responsible to call the original database interface to fulfill a request.

Event Interception

The plugin can insert itself into the event notification lists for individual fields (express interest in a field? subscribe to a field?) and hence get called in the context of the db_post_event() call (or equivalent) of the record's process() routine.

Within that callback the plugin can issue additional db_post_event() calls for its own properties that are added to the record's property catalog.

Configuration

Default configuration is by means of Information Fields, so that the database designer can configure plugin functionalities for specific records and fields.

On-line configuration can be done by calling functions from the IOCshell command line. This provides a way to override a default database configuration from within the startup script before IOCinit() is called.

On-line configuration can be done through Channel Access. The plugin can provide special channels that allow CA clients to start/stop/configure functionality for a certain record/field.

Implementation Ideas

DA Extension/Override

This is probably not easy to do, if we want to avoid unwanted performance hits.

As plugin functionality may start when the IOC is already up and running, the plugin has to interpose a DA interface onto an existing one created from the EPICS database. If there are active connections between the database record and CA, the server library probably already holds a pointer to the database's DA property catalog. Hard to get inbetween there without adding a layer of indirection or dereferencing that has to be executed every time the record is accessed.

How will name resolution on the IOC (i.e. finding the DA property catalog for a given record name) be organised? Is there a name resolution service that the database registers the records with? If that is done through an API, the plugin could register for the same record providing its property catalog. Still - is there a chance to interpose a DA interface that already has been handed over to the CA server library?

Or should the record support itself provide an interface that the plugin can register its additional property catalog with? In that case the "outer" DA interface would stay the same, the CA server lib could continue to use the pointer it was given. The record's property list itself would merge in additional properties from plugins. Seems like a wild mess between layers that should be well separated, but could be quite efficient and doesn't introduce overhead for records and fields that are not used by the plugin. Ao the record would not just hold the configuration data for plugins (in a generic opaque way), but also forward the additional properties provided by the plugin.

Event Interception

This sounds easier to accomplish. There probably is some kind of event broker or distributor module that forwards events from sources (like the EPICS database) to interested receivers (like the CA server library or a plugin). This event broker should have an API to allow receivers to register for updates on a certain record/field.