V4 Server Side Plugins - Revision history

RalphLange: /* Configuration */ += registration

2005-07-14T22:26:19Z

Configuration: += registration

← Older revision		Revision as of 22:26, 14 July 2005
Line 51:		Line 51:
	''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.''		''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~~.		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 ===		=== 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.		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.

RalphLange: /* Implementation Ideas */ fix

2005-07-14T22:12:56Z

Implementation Ideas: fix

← Older revision		Revision as of 22:12, 14 July 2005
Line 52:		Line 52:

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

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

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

RalphLange: /* Configuration */ += persistence issues

2005-07-14T22:11:59Z

Configuration: += persistence issues

← Older revision		Revision as of 22:11, 14 July 2005
Line 52:		Line 52:

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

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

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

RalphLange: /* Configuration */ += persistence issues

2005-07-14T22:11:54Z

Configuration: += persistence issues

← Older revision		Revision as of 22:11, 14 July 2005
Line 52:		Line 52:

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

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

RalphLange: General update; more input from Andrew and Benjamin; implementation ideas getting more complete and more coherent

2005-06-23T13:54:09Z

General update; more input from Andrew and Benjamin; implementation ideas getting more complete and more coherent

← Older revision		Revision as of 13:54, 23 June 2005
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.

RalphLange at 12:26, 23 June 2005

2005-06-23T12:26:10Z

← Older revision		Revision as of 12:26, 23 June 2005
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.

RalphLange: /* Configuration */ Clarification

2005-06-07T20:07:24Z

Configuration: Clarification

← Older revision		Revision as of 20:07, 7 June 2005
Line 24:		Line 24:
	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 ==

RalphLange: /* DA Extension/Override */ Spelling / Clarification

2005-06-07T20:04:59Z

DA Extension/Override: Spelling / Clarification

← Older revision		Revision as of 20:04, 7 June 2005
Line 32:		Line 32:
	This is probably not easy to do, if we want to avoid unwanted performance hits.		This is probably not easy to do, if we want to avoid unwanted performance hits.

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

RalphLange at 20:02, 7 June 2005

2005-06-07T20:02:35Z

← Older revision		Revision as of 20:02, 7 June 2005
Line 1:		Line 1:
	~~= Possible Interfaces~~ and ~~Designs for 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'''''		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 [[V4 DB Record Instance Syntax#Information Fields\|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 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.

			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.

RalphLange at 06:34, 6 May 2005

2005-05-06T06:34:45Z

← Older revision		Revision as of 06:34, 6 May 2005
Line 1:		Line 1:
	= Server Side Plugins =		= Possible Interfaces and Designs for V4 Server Side Plugins =
	aka '''''Circular Buffy, the Vampire Layer'''''		aka '''''Circular Buffy, the Vampire Layer'''''