Difference between revisions of "V4 Server Side Plugins"

From EPICSWIKI
(→‎Configuration: += registration)
 
(7 intermediate revisions by the same user not shown)
Line 9: 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 24: Line 25:
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 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.
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 ==
== Implementation Ideas ==
Line 30: 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 during the IOC run, the plugin has to interpose a DA interface onto an existing one created from the EPICS database. If there are active connections between teh database record and CA, the server library probably 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.''
 
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, ...<br>
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.

Latest revision as of 22:26, 14 July 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.

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.

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