V4 2nd Design Meeting Notes - Revision history

RalphLange: Moved to the Ancient V4 Section and added author

2008-04-15T03:17:11Z

Moved to the Ancient V4 Section and added author

← Older revision		Revision as of 03:17, 15 April 2008
Line 1:		Line 1:
	== 2nd Design Meeting (APS) - Notes ==		== 2nd Design Meeting (APS) - Notes by [[User:RalphLange\|Ralph Lange]] ==

	=== Who is the customer? ===		=== Who is the customer? ===

RalphLange: /* Other Things in the Pipeline */

2007-04-27T13:49:36Z

Other Things in the Pipeline

← Older revision		Revision as of 13:49, 27 April 2007
Line 146:		Line 146:

	== Other Things in the Pipeline ==		== Other Things in the Pipeline ==

	~~[[How to Set Up a Soft IOC Framework on Linux]]~~

	~~[[How to Set Up Console Access and Logging for VME and Soft IOCs]]~~

RalphLange: /* Other Things in the Pipeline */

2007-04-25T15:42:49Z

Other Things in the Pipeline

← Older revision		Revision as of 15:42, 25 April 2007
Line 148:		Line 148:

	[[How to Set Up a Soft IOC Framework on Linux]]		[[How to Set Up a Soft IOC Framework on Linux]]

			[[How to Set Up Console Access and Logging for VME and Soft IOCs]]

RalphLange at 15:36, 16 March 2007

2007-03-16T15:36:49Z

← Older revision		Revision as of 15:36, 16 March 2007
Line 144:		Line 144:

	CA might implement a per client filter to get more efficient filtering in cases where a bunch of clients (e.g. everything from a certain beamline or different archivers) use the same filter (e.g. "only blue beam"). In that case it would be possible for the server to put the filter ''in front'' of the multiple event queues to avoid processing it once for each client.		CA might implement a per client filter to get more efficient filtering in cases where a bunch of clients (e.g. everything from a certain beamline or different archivers) use the same filter (e.g. "only blue beam"). In that case it would be possible for the server to put the filter ''in front'' of the multiple event queues to avoid processing it once for each client.

			== Other Things in the Pipeline ==

			[[How to Set Up a Soft IOC Framework on Linux]]

RalphLange: /* Data Access */

2005-07-14T21:47:11Z

Data Access

← Older revision		Revision as of 21:47, 14 July 2005
Line 61:		Line 61:

	The presented first version of a third set of traverse and find methods to find out the native types of properties does not seem to be efficient and desirable.		The presented first version of a third set of traverse and find methods to find out the native types of properties does not seem to be efficient and desirable.

			==== Traversal ====

			A Viewer or Manipulator should have a way to stop further traversal of data. Throwing an exception is probably too expensive an opereration for that - can we use a return value that the Viewer/Manipulator returns.

	=== CA/DA Convenience layer / user interface ===		=== CA/DA Convenience layer / user interface ===

RalphLange: /* Event distribution and event queues */

2005-07-14T20:51:47Z

Event distribution and event queues

← Older revision		Revision as of 20:51, 14 July 2005
Line 122:		Line 122:

	Benefit of fixed size:		Benefit of fixed size:
	* Reading out is very fast.		* Reading out in terms of DataAccess is very fast.
	Downside:		Downside:
	* For a given event, the catalog is fixed. There is no way to ask for "the left bacon stretcher" whenever an "alarm change" event occurs.		* For a given event, the catalog is fixed. There is no way to ask for "the left bacon stretcher" whenever an "alarm change" event occurs.

RalphLange: /* Event distribution and event queues */

2005-07-14T20:51:11Z

Event distribution and event queues

← Older revision		Revision as of 20:51, 14 July 2005
Line 121:		Line 121:
	Big question: Should we put fixed size data chunks on the event queues or allow variable sized data chunks?		Big question: Should we put fixed size data chunks on the event queues or allow variable sized data chunks?

	Benefit of fixed size: ~~reading~~ out is very fast.~~<br>~~		Benefit of fixed size:
	Downside: ~~for~~ a given event, the catalog is fixed. There is no way to ask for "the left bacon stretcher" whenever an "alarm change" event occurs.~~<br>~~		* Reading out is very fast.
	Clients that want to use new event types have to be recompiled.		Downside:
			* For a given event, the catalog is fixed. There is no way to ask for "the left bacon stretcher" whenever an "alarm change" event occurs.
			* Clients that want to use new event types have to be recompiled.

	Benefit of variable size: ~~catalogs~~ are completely independent from events. Events are pure filters that defines ''when'' something will be sent while the property catalog defines ''what'' will be sent.~~<br>~~		Benefit of variable size:
	The mechanisms are very similar to things in the [[V4 Data Store]], so that some mechanisms (scanning the catalog to determine storage sizes, using fixes sized free lists) might be shared or reused.		* Catalogs are completely independent from events. Events are pure filters that defines ''when'' something will be sent while the property catalog defines ''what'' will be sent.
	Downside: Double scanning and making the property catalog aware of "dirty" or "in use" bits will lead to a hit in performance.		* The mechanisms are very similar to things in the [[V4 Data Store]], so that some mechanisms (scanning the catalog to determine storage sizes, using fixes sized free lists) might be shared or reused.
			Downside:
			* Double scanning and making the property catalog aware of "dirty" or "in use" bits will lead to a hit in performance.

	==== Filtering ====		==== Filtering ====

RalphLange at 20:44, 14 July 2005

2005-07-14T20:44:14Z

← Older revision		Revision as of 20:44, 14 July 2005
Line 48:		Line 48:
	(This might map to a numeric property address - using an array of propertyIds - when transferred over CA.)		(This might map to a numeric property address - using an array of propertyIds - when transferred over CA.)

	Clients should be able to find out if a certain property implements "analog", "enumerated", or "string" behaviour. (To make handling unknown properties easier .) Making the IOC answer these kind of questions induces a number of problems (versioning etc.) It might be possible to implement these "types" of properties as a conveniency layer library on the client side.		Clients should be able to find out if a certain property implements "analog", "enumerated", or "string" behaviour. (To make handling unknown properties easier.) Making the IOC answer these kind of questions induces a number of problems (versioning etc.) It might be possible to implement these "types" of properties as a conveniency layer library on the client side.

	=== Record instance syntax ===		=== Record instance syntax ===
Line 121:		Line 121:
	Big question: Should we put fixed size data chunks on the event queues or allow variable sized data chunks?		Big question: Should we put fixed size data chunks on the event queues or allow variable sized data chunks?

	Benefit of fixed size: reading out is very fast.<nl>		Benefit of fixed size: reading out is very fast.<br>
	Downside: for a given event, the catalog is fixed. There is no way to ask for "the left bacon stretcher" whenever an "alarm change" event occurs.<nl>		Downside: for a given event, the catalog is fixed. There is no way to ask for "the left bacon stretcher" whenever an "alarm change" event occurs.<br>
	Clients that want to use new event types have to be recompiled.		Clients that want to use new event types have to be recompiled.

	Benefit of variable size: catalogs are completely independent from events. Events are pure filters that defines ''when'' something will be sent while the property catalog defines ''what'' will be sent.<nl>		Benefit of variable size: catalogs are completely independent from events. Events are pure filters that defines ''when'' something will be sent while the property catalog defines ''what'' will be sent.<br>
	The mechanisms are very similar to things in the [[V4 Data Store]], so that some mechanisms (scanning the catalog to determine storage sizes, using fixes sized free lists) might be shared or reused.		The mechanisms are very similar to things in the [[V4 Data Store]], so that some mechanisms (scanning the catalog to determine storage sizes, using fixes sized free lists) might be shared or reused.
			Downside: Double scanning and making the property catalog aware of "dirty" or "in use" bits will lead to a hit in performance.

	==== Filtering ====		==== Filtering ====

RalphLange: /* Event distribution and event queues */

2005-07-14T20:08:06Z

Event distribution and event queues

← Older revision		Revision as of 20:08, 14 July 2005
Line 117:		Line 117:
	The database will have to send up every change for a record's fields. [[V4 View Generated Code]] shows how the Data Access code for views is generated from dbd.		The database will have to send up every change for a record's fields. [[V4 View Generated Code]] shows how the Data Access code for views is generated from dbd.

	The ~~database creates~~ catalog~~-interfaced containers~~ for ~~changes~~.		The record processing (as well as dbPutField) will post changes to ''fields''. Decoupling of the changes done by independent entities (e.g. record processing and CA puts) will be through a transaction type operation. At the beginning of an operation, a transaction object is created (holding the dirty bits array). A reference to that transaction object ist returned to the user. This reference is passed in with every change of a field, so that it sets the according dirty bit. The flush call will post all fields that have been marked dirty for this transaction.

			Big question: Should we put fixed size data chunks on the event queues or allow variable sized data chunks?

			Benefit of fixed size: reading out is very fast.<nl>
			Downside: for a given event, the catalog is fixed. There is no way to ask for "the left bacon stretcher" whenever an "alarm change" event occurs.<nl>
			Clients that want to use new event types have to be recompiled.

			Benefit of variable size: catalogs are completely independent from events. Events are pure filters that defines ''when'' something will be sent while the property catalog defines ''what'' will be sent.<nl>
			The mechanisms are very similar to things in the [[V4 Data Store]], so that some mechanisms (scanning the catalog to determine storage sizes, using fixes sized free lists) might be shared or reused.

	==== Filtering ====		==== Filtering ====

RalphLange: /* IOC middle layer */

2005-07-14T16:13:42Z

IOC middle layer

← Older revision		Revision as of 16:13, 14 July 2005
Line 116:		Line 116:

	The database will have to send up every change for a record's fields. [[V4 View Generated Code]] shows how the Data Access code for views is generated from dbd.		The database will have to send up every change for a record's fields. [[V4 View Generated Code]] shows how the Data Access code for views is generated from dbd.

			The database creates catalog-interfaced containers for changes.

	==== Filtering ====		==== Filtering ====