Difference between revisions of "V4 Server Side Plugins"

From EPICSWIKI
m
(General update; more input from Andrew and Benjamin; implementation ideas getting more complete and more coherent)
Line 1: Line 1:
<font size="+3" color="red">'''''Currently undergoing off-line changes - do not edit'''''</font>
: 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.
: 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.


Line 11: Line 9:
=== DA Extension/Override ===
=== 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
The plugin can add views to a record's DA interface.
interface to fulfill a request.
 
Adding properties to existing views or replacing properties will not be supported.


=== Event Interception ===
=== Event Interception ===
Line 32: Line 31:
=== DA Extension/Override ===
=== DA Extension/Override ===


This is probably not easy to do, if we want to avoid unwanted performance hits.
''The plugin can add views to a record's DA interface.''


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.
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.


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?
''Adding properties to existing views or replacing properties will not be supported.''


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.
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 ===
=== 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.
''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.''
 
How will name resolution on the IOC (i.e. finding the DA property catalog for a given record name) be organised? If the Vampire wants to add channels that can be used to control and/or monitor its configuration and performance, there must be an interface at some point where names can be registered on an IOC.

Revision as of 13:54, 23 June 2005

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.

How will name resolution on the IOC (i.e. finding the DA property catalog for a given record name) be organised? If the Vampire wants to add channels that can be used to control and/or monitor its configuration and performance, there must be an interface at some point where names can be registered on an IOC.

Retrieved from "https://wiki-ext.aps.anl.gov/epics/index.php?title=V4_Server_Side_Plugins&oldid=428"