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 add views to a record's DA interface.

Adding properties to existing views or replacing properties will not be supported.

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 provides special channels that allow CA clients to start/stop/configure functionality for a certain record/field.

Implementation Ideas

DA Extension/Override

The plugin can add views to a record's DA interface.

The record should provide an interface to register (and unregister) additional views at runtime. (see also Andrew's mail on "Re: Property catalogs" of May 13). The record will at all times be the key manager of its property catalogs - it is the model in the MVC view, that all views and controllers will have to register with.

Adding properties to existing views or replacing properties will not be supported.

In these cases the traverse() methods would have to perform an on-line merge between multiple property catalogs. They would have to implement special Viewers and Manipulators that scan and merge property catalogs to find out what properties (from which catalog) should really be exported before doing the export itself in a second step. This sounds just too awkward and complicated to do and would either require a second scan or locally buffering of all the data. Both of which would generate a noticeable performance and/or memory usage hit for the traversing methods.

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.

This sounds easier to accomplish. There should be 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 will have an API to allow receivers to register for updates on a certain record/property catalog. While the CA server will provide a callback that puts the event on the event queue(s), the vampire will execute its functional

Configuration

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

The Vampire will register in two ways/places:

It will be a V4 IOC service and through this interface provide channels for general configuration, diagnostics, attaching and detaching to/from channels.

When attaching to a new channel (property, property catalog), the Vampire will register a new view for the record with the ViewManager. That way the new view will be visible for all servers on the IOC. From that point on it can be accessed by links, CA, ...
The Vampire can also add another view containing properties to configure that particular Vampire connection.

Persistence

The Vampire must be save/restore aware. I.e. it must provide channels through its service interface that make it configurable, in a way that allows save/restore to save Vampire connections and recreate them at boot time.