V4 CA Client User Interface - Revision history

KayKasemir: TIPC

2005-07-16T19:13:44Z

TIPC

← Older revision		Revision as of 19:13, 16 July 2005
Line 14:		Line 14:
	Is there anything we can learn from other communication libraries?		Is there anything we can learn from other communication libraries?
	* A brief look at [[ZeroC ICE]]		* A brief look at [[ZeroC ICE]]
			* TIPC, the Transparent Inter Process Communication protocol (TIPC) started out as a communications layer for building clusters, I think by Ericson, and is now becoming more open and also supported by the latest WindRiver vxWorks releases.<br>The Buzz:
			** allows socket-based applications to communicate easily and efficient
			** based on publicly available source code
			** A location-transparent addressing scheme
			** Efficient, rapid, and reliable interprocess communication within a node and between nodes, using either connection-oriented or connectionless modes of operation
			** Rapid notification of changes in topology and the ability to adjust quickly to these changes

	== Constraints ==		== Constraints ==

KayKasemir: start over with requirements, dropping details that are controversial

2005-07-16T05:10:53Z

start over with requirements, dropping details that are controversial

← Older revision		Revision as of 05:10, 16 July 2005
Line 45:		Line 45:

	=== Data ===		=== Data ===
	~~All the~~ data ~~is accessed via DataAccess~~, ~~which handles the introspection~~		The available ''data'' constists of property names, types and values, for example:
	of ~~arbitrary~~ data ~~types~~. The ~~existing dataAccess interface is based on~~		double value; // The "value" property of our data
	~~a visitor pattern.~~ The user ~~cannot list~~ the ~~available~~ properties ~~nor pick~~		string units; // The "units" property....
	~~a selected property. Instead~~, the user ~~can request complete traversal~~		time_stamp time;
	~~or a callback~~ for ~~a specific property~~.
			The data might contain arrays and structures.
			The user might not want all the properties, and the user might also want to get properties in non-native types (strings for convenience, float instead of double to preserve space, ...).
			The client has to provide storage, and might allocate this:
			float value;
			string units;

	~~This might be the most efficient implementation, but not necessarily~~		The user interface must provide the following:
	~~the one that's easiest to understand.~~ The user interface ~~to dataAccess~~		* getAllProperties()<BR>Get a list of all the property names and their data type so that the client can make an informed decision for allocating its storage of the data. There might be helper routines to convert between human-usable strings and more efficient numeric identifiers.
	~~should thus also~~ provide the following ~~convenience routines~~:		* bool hasWriteAccess(string property)<BR>Could also be part of the info return by previous method.
	* ~~list<string> getProperties~~()<BR>Get a list of all the ~~properties~~
	* type_info getType(string property)
	* bool hasWriteAccess(string property)
	* string getAsString(string property)

	~~Marty has a more complete idea~~, ~~where a proterty catalog converts strings~~ to ~~IDs~~		This functionality is available without getting any actual data.
	~~and then those are actually used to access~~ the data:		To retrieve values, the user asks the client library to place the data into
			the client-provided storage.
	~~struct Property {~~		The ''traverse'' of the "dataAccess" proposal handles this by asking
	~~epicsInt32 id;~~		the user to implement a property catalog that ''reveals'' each storage element.
	~~dbfType type;~~		The end effect is not too different from having the user invoke methods
	~~void *pdbf;~~		like these:
	};		* getAsString(string property, string *my_storage)
	~~interface PropertyViewer {~~		* getAsDouble(string property, double *my_storage)
	~~Property~~ *~~getFirst~~();		* ...many more, one for each available data type.
	~~Property~~ *~~getNext~~(~~Property &);~~
	~~Property~~ *~~get(epicsInt32 id~~);
	}
	~~interface PropertyCatalogManager {~~
	~~epicsInt32 getId(EpicsString &);~~
	~~EpicsString~~ *~~getName(epicsInt32 id);~~
	~~epicsInt32 createId(EpicsString &);~~
	};

	~~In the following~~, each ~~method that uses the property name~~
	will need a twin that uses the ID or Property *.

	=== Channel ===		=== Channel ===

KayKasemir: /* Data Access */

2005-07-14T20:36:39Z

Data Access

← Older revision		Revision as of 20:36, 14 July 2005
Line 44:		Line 44:
	See separate [[V4 Name Server]] wiki for the issue of "record" and "PV" information.		See separate [[V4 Name Server]] wiki for the issue of "record" and "PV" information.

	=== Data ~~Access~~ ===		=== Data ===
	All the data is accessed via DataAccess, which handles the introspection		All the data is accessed via DataAccess, which handles the introspection
	of arbitrary data types. It should provide the following convenience		of arbitrary data types. The existing dataAccess interface is based on
	routines ~~in addition to whatever more efficient methods it might have~~		a visitor pattern. The user cannot list the available properties nor pick
	~~(using hash IDs instead property name string etc.)~~:		a selected property. Instead, the user can request complete traversal
			or a callback for a specific property.

			This might be the most efficient implementation, but not necessarily
			the one that's easiest to understand. The user interface to dataAccess
			should thus also provide the following convenience routines:
	* list<string> getProperties()<BR>Get a list of all the properties		* list<string> getProperties()<BR>Get a list of all the properties
	* type_info getType(string property)		* type_info getType(string property)

KayKasemir: /* Channel: Writing */

2005-07-14T20:19:17Z

Channel: Writing

← Older revision		Revision as of 20:19, 14 July 2005
Line 112:		Line 112:
	=== Channel: Writing ===		=== Channel: Writing ===
	* write(new value)<BR>Sends the value to the server.		* write(new value)<BR>Sends the value to the server.
	* createWriteRequest(new value, receipt {delivery, completion})<BR>Sends the value to the server, invokes Listener when CA server has received the value ~~respectively~~ all the processing triggered by the new value has completed.		* createWriteRequest(new value, receipt {delivery, completion, response})<BR>Sends the value to the server, invokes Listener when CA server has received the value (delivery) or all the processing triggered by the new value has completed (completion). In addition, some records might support command/response, in which case one can write a command and wait for a response callback which looks just like the result of a read request.
	* scheduleWriteRequest(new value, event)<BR>Sends the value to the server, which will perform the write when the given event fires. Invokes Listener when CA server has performed the write.		* scheduleWriteRequest(new value, event)<BR>Sends the value to the server, which will perform the write when the given event fires. Invokes Listener when CA server has performed the write.

KayKasemir at 17:52, 14 July 2005

2005-07-14T17:52:24Z

← Older revision		Revision as of 17:52, 14 July 2005
Line 19:		Line 19:
	* Should very easily translate into Java, just like e.g. some XML APIs use the exact same classes and methods in C++ and Java. Ideally, Java and C++ version will be available from the start.		* Should very easily translate into Java, just like e.g. some XML APIs use the exact same classes and methods in C++ and Java. Ideally, Java and C++ version will be available from the start.
	* Ideally, the C++ headers would be simple enough to be parsed by SWIG and hence perl/tcl/python/... glue code could be auto-generated via SWIG		* Ideally, the C++ headers would be simple enough to be parsed by SWIG and hence perl/tcl/python/... glue code could be auto-generated via SWIG
			* API is of course specific to EPICS CA, but ideally it'll also be usable as an interface to other protocols, so that EPICS Office can use an API that is only a slight extension of the CA client user API.
	~~== Constraints ==~~
	* ~~Initial implementation will~~ be ~~in C++~~
	* Should very easily translate into Java, ~~just like e.g. some XML APIs~~ use the ~~exact same classes and methods in C++ and Java. Ideally, Java and C++ version will be available from the start.~~
	* Ideally, the C++ headers would be simple enough to be parsed by SWIG and hence perl/tcl/python/.~~.. glue code could be auto-generated via SWIG~~

	== Skeleton API ==		== Skeleton API ==

KayKasemir: Constraints

2005-07-14T17:50:35Z

Constraints

← Older revision		Revision as of 17:50, 14 July 2005
Line 14:		Line 14:
	Is there anything we can learn from other communication libraries?		Is there anything we can learn from other communication libraries?
	* A brief look at [[ZeroC ICE]]		* A brief look at [[ZeroC ICE]]

			== Constraints ==
			* Initial implementation will be in C++
			* Should very easily translate into Java, just like e.g. some XML APIs use the exact same classes and methods in C++ and Java. Ideally, Java and C++ version will be available from the start.
			* Ideally, the C++ headers would be simple enough to be parsed by SWIG and hence perl/tcl/python/... glue code could be auto-generated via SWIG

	== Constraints ==		== Constraints ==

KayKasemir: Constraints

2005-07-14T17:50:30Z

Constraints

← Older revision		Revision as of 17:50, 14 July 2005
Line 14:		Line 14:
	Is there anything we can learn from other communication libraries?		Is there anything we can learn from other communication libraries?
	* A brief look at [[ZeroC ICE]]		* A brief look at [[ZeroC ICE]]

			== Constraints ==
			* Initial implementation will be in C++
			* Should very easily translate into Java, just like e.g. some XML APIs use the exact same classes and methods in C++ and Java. Ideally, Java and C++ version will be available from the start.
			* Ideally, the C++ headers would be simple enough to be parsed by SWIG and hence perl/tcl/python/... glue code could be auto-generated via SWIG

	== Skeleton API ==		== Skeleton API ==

KayKasemir: /* ChannelGroup */

2005-07-13T20:38:58Z

ChannelGroup

← Older revision		Revision as of 20:38, 13 July 2005
Line 130:		Line 130:

	=== ChannelGroup ===		=== ChannelGroup ===

	A channel group synchronizes access to multiple channels.		A channel group synchronizes access to multiple channels.
	It listens to all members of the channel group and for example		It listens to all members of the channel group and for example
	allows waiting for ''all'' outstanding read or write requests		allows waiting for ''all'' outstanding read or write requests
	to return.		to return.

			* add/remove channels<br>By name? Already existing Channel? Add channels that match a pattern, or go via the directory?
			* read/write<br>Has to handle reading/writing the same properties from all channels in group. Also channel-specific list of properties?

	=== SyncChannel ===		=== SyncChannel ===

KayKasemir: /* Channel: State */

2005-07-13T20:23:35Z

Channel: State

← Older revision		Revision as of 20:23, 13 July 2005
Line 102:		Line 102:
	* bool isConnected()<BR> .. for those who want to poll		* bool isConnected()<BR> .. for those who want to poll
	* xxx getServerInfo(), xxx getType()<BR> .. only valid when isConnected().		* xxx getServerInfo(), xxx getType()<BR> .. only valid when isConnected().
	* setUser(), ...<BR>Sets/changes the 'user' that determines the access rights, allowing OPI tools to adjust this per-channel at runtime.		* setUser(), ...<BR>Sets/changes the 'user' that determines the access rights, allowing OPI tools to adjust this per-channel at runtime. To avoid security issues, setUser will probably send a public key and not a user name and password.

	=== Channel: Writing ===		=== Channel: Writing ===

KayKasemir: /* SyncChannel */ , ChannelGroup

2005-07-13T20:22:30Z

SyncChannel: , ChannelGroup

← Older revision		Revision as of 20:22, 13 July 2005
Line 128:		Line 128:
	* string toString()		* string toString()
	* bood fromString(string event_specification)		* bood fromString(string event_specification)

			=== ChannelGroup ===

			A channel group synchronizes access to multiple channels.
			It listens to all members of the channel group and for example
			allows waiting for ''all'' outstanding read or write requests
			to return.

	=== SyncChannel ===		=== SyncChannel ===