| 2002 2003 2004 2005 2006 2007 2008 <2009> 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 <2009> 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: Ideas for Codeathon |
| From: | Marty Kraimer <[email protected]> |
| To: | Jeff Hill <[email protected]> |
| Cc: | [email protected], Matej Sekoranja <[email protected]> |
| Date: | Thu, 19 Feb 2009 15:40:36 -0500 |
I have attached the overview document for a new project called pvData. pvData is the the next version of the data portion of the JavaIOC. The xml syntax is completely different (due to comments from Matej and Andrew). The types are simplified due to discussions with Matej. The pvData project has what is required for data handling and can be used by more than the JavaIOC. The next release of the JavaIOC will use pvData instead of pvData being part of the javaIOC.
Marty Jeff Hill wrote:
*6. CA Support for "Our ArchiveRecord" and Others* The DESY archive record samples "value, time and severity" into an array of structures. Unfortunately we can not pass this array over channel access directly (as far as I know). So we have additional arrays with value (double), seconds_epoch (ulong), nanoseconds (ulong) and severity (short). It would be better and more safe (locking is not provided well now) if we could use something like an array of "DBR_TIME_DOUBLE_STAT_SEVR (or so).I will leave Jeff Hill to comment on the feasibility of adding new request types like this and the idea below to CA.The quick answer is that there are two ways to do this.1) We certainly can code new data types into the db_access data model. The primary obstacle to overcome, when satisfying your request, will be that CA and db_access both currently expect that arrays occur only with the value field, and that the value field is always the last field in the structure. Thus, making arrays of DBR_TIME_DOUBLE_STAT_SEVR tends to break data model consistency in a number of important places. In the CA client API, CA client library, in the CA protocol, in the CA server, and in the database library. I think that an inconsistent approach to arrays in the legacy CA client API is what we might be most fearful of. Furthermore, I think it's safe to say that the scale of the changes in the base codes is not making this appropriate for an R3.14 patch.2) So it appears that we need a better API and when we make that jump it's important to adopt a flexible approach which will accommodate future needs. What we really need is more flexible APIs so we can have generalized client and service specified formats for aggregating data. I have written a design document (it's on the wiki) describing a new protocol that can have this level of flexibility, but for R3.15 we are concentrating only on new flexibility allowing service specified formats for aggregating data on the server's (IOC's) event queue, and on an ability for clients to specify in their subscriptions generic filtering expressions that test service specific parameters determining which subscription updates will be sent. We admit to being strongly requirements driven for our upgrade here at LANSCE, but nevertheless we are committed to a very general approach which should have excellent utility for the community.To summarize, the db_access data model has many severe constraints, but changing the model to make its approach to arrays inconsistent may not be a great strategy, and making large changes in R3.14 probably isn’t a robustness enhancing strategy either. From my perspective, the Data Access library is the proper flexible, runtime bound, API for accessing client/service specified data aggregation formats that we will need in the future. Furthermore, wire protocol flexibility for client / service specified data formats is not on the short list, but event queue flexibility and API flexibility is. Once the near term event queue goals and API upgrades are done, then wire protocol flexibility looks like a logical next step. I admit to working specifically on LANSCE's immediately needs for its upgrade, and while protocol flexibility is certainly going to be very useful here it hasn’t been given as high a priority near term as the event queue changes. Jeff
Title: EPICS PVData
This product is available via the open source license described at the end of this document.
PVData (Process Variable Data) defines and implements an efficent way to store, access, and transmit memory resident structured data.
A Process Variable (PV) Database, which is a memory resident database holding PVData, has the following features:
PVData was initially created to support the JavaIOC and was part of the JavaIOC project. It is now a separate project that is used by the JavaIOC. In addition to the JavaIOC, PVData is intended for use by 1) Channel Access Client, 2) Interface between client and network, 3) Interface between network and Channel Access server, 4) Interface between Server and IOC database. Since it is an interface to data, it could also be used by other systems, e.g. TANGO, TINE, etc. A high level Physics application can hold data as PVData. By starting a channel access server, the data can made available to network clients.
PVData contains everything required to support Channel Access and Channel Access clients and servers.
The following are the type definitions:
public enum Type {
scalar,
scalarArray,
structure;
}
public enum ScalarType {
pvBoolean,
pvByte,pvShort,pvInt,pvLong,
pvFloat,pvDouble,
pvString;
// The following are convenience methods
public boolean isInteger();
public boolean isNumeric()
public boolean isPrimitive()
public static ScalarType getScalarType(String type);
}
The complete set of introspection interfaces are:
public interface Field extends Serializable {
String getFieldName();
Type getType();
}
public interface Scalar extends Field{
ScalarType getScalarType();
}
public interface Array extends Field{
ScalarType getElementType();
}
public interface Structure extends Field{
String[] getFieldNames();
Field getField(String fieldName);
int getFieldIndex(String fieldName);
Field[] getFields();
}
The introspection interfaces provide access to immutable objects. This allows introspection interfaces to be freely shared between data objects. For example the introspection interface for a timeStamp, which is a structure containing two fields, can be stared by every record that has a time stamp.
PVField is the base interface for a data field:
public enum MessageType {info,warning,error,fatalError}
public interface Requester {
String getRequesterName();
void message(String message, MessageType messageType);
}
public interface Serializable {
void serialize(ByteBuffer buffer);
int getSerializationSize();
void deserialize(ByteBuffer buffer);
}
public interface PVAuxInfo {
PVField getPVField();
PVScalar createInfo(String key,ScalarType scalarType);
Map<String,PVScalar> getInfos();
PVScalar getInfo(String key);
}
public interface PVField extends Requester, Serializable {
Field getField();
PVStructure getParent();
PVRecord getPVRecord();
String getFullFieldName();
String getFullName();
PVAuxInfo getPVAuxInfo(); //auxillary information
boolean isMutable();
void setMutable(boolean value);
void replacePVField(PVField newPVField);
// following methods are for monitoring changes
boolean addListener(PVListener pvListener);
void removeListener(PVListener pvListener);
void postPut();
}
Each scalar type has an associated data interface: PVBoolean, PVByte, PVShort, PVInt, PVLong, PVFloat, PVDouble, and PVString. Each has a get and a put method. For example:
public interface PVDouble extends PVScalar{
double get();
void put(double value);
}
PVArray is the base class for arrays.
public interface PVArray extends PVField{
Array getArray();
int getLength();
void setLength(int len);
int getCapacity();
void setCapacity(int len);
boolean isCapacityMutable();
void setCapacityMutable(boolean isMutable);
}
For each scalar type an associated array data interface is defined. Each has a get and put method. For example:
public class DoubleArrayData {
public double[] data;
public int offset;
}
public interface PVDoubleArray extends PVArray{
int get(int offset, int len, DoubleArrayData data);
int put(int offset,int len, double[] from, int fromOffset);
}
PVStructure is the data interface for a structure.
public interface PVStructure extends PVField {
Structure getStructure();
PVField[] getPVFields();
PVField getSubField(String fieldName);
boolean replaceStructureField(String fieldName,Structure structure);
void appendPVField(PVField pvField);
void postPut(PVField subField);
// The following are convenience methods
PVBoolean getBooleanField(String fieldName);
PVByte getByteField(String fieldName);
PVShort getShortField(String fieldName);
PVInt getIntField(String fieldName);
PVLong getLongField(String fieldName);
PVFloat getFloatField(String fieldName);
PVDouble getDoubleField(String fieldName);
PVString getStringField(String fieldName);
PVStructure getStructureField(String fieldName);
PVArray getArrayField(String fieldName,ScalarType elementType);
}
The following interface creates introspection instances:
public interface FieldCreate {
Scalar createScalar(String fieldName,ScalarType scalarType);
Array createArray(String fieldName,ScalarType elementType);
Structure createStructure(String fieldName, Field[] field);
}
The following interface creates data instances:
public interface PVDataCreate {
PVField createPVField(PVStructure parent, Field field);
PVScalar createPVScalar(PVStructure parent,Scalar scalar);
PVScalar createPVScalar(PVStructure parent,String fieldName,
ScalarType fieldType);
PVArray createPVArray(PVStructure parent,Array array);
PVArray createPVArray(PVStructure parent,String fieldName,
ScalarType elementType);
PVStructure createPVStructure(PVStructure parent,String fieldName,
Field[] fields);
PVStructure createPVStructure(PVStructure parent,String fieldName,
PVStructure structToClone);
PVStructure createPVStructure(PVStructure parent,String fieldName,
PVDatabase pvDatabase,String structureName);
PVRecord createPVRecord(String recordName,Field[] fields);
PVRecord createPVRecord(String recordName,PVStructure structToClone);
PVRecord createPVRecord(String recordName,PVDatabase pvDatabase,
String structureName);
}
An interface named Convert provides all reasonable conversions to/from PVData. See org.epics.pvData.pv.Convert for details.
This document describes everything via Java definitions. The initial implementation is in Java but the functionality could also be implemented in other languages such as C++.
PVData is distributed as a eclipse Java Project named pvData. This project consists of the following java packages:
The Java enum, interface, and class definitions that define PVData. This section provides a complete definition of what PVData is. This package completely describes how PVData is accessed.
Java Facilities for creating a PV Database and PVData. It provides everything required for creating PVData. It provides the following factories:
Although PVDataFactory can provide the implementation for all supported data types, often it is desirable to provide other implementations. To make it easy to create alternate implementations a set of abstract and base classes are supplied.
Provides a way to associated properties with a field.
The basic idea is to associate properties with any field named "value". All the fields in the structure that contains the value field are considered properties of value with the field name being the property name. See that package overview for details.
This package also provides support for "well known" field definitions like timeStamp, alarm, display,etc. Code that uses PVData can be simplified by using this support.
One way to create a PV database is via an xml parser. This package defines the syntax and provides a parser.
This package provides support that is used by pvData factories and might also be useful to software that uses PVData.
Test code.
How should properties be associated with a field? Package org.epics.pvData.property shows one way of assigning properties. Is this what is desired? No matter what a property should end up producing a PVField interface.
Do we also want attributes for a field? Are both property and attribute desirable?
Although this document does not discuss remote procedure calls, an RPC facility could easily be implemented via PVData. The following is a possible interface for a remote procedure call.
interface PVRPC {
PVString methodName;
PVStructure arguments;
PVStructure result;
}
The Channel access methods can be implemented via a PVRPC. Method names would be something like: get, put, putGet, processGet, putProcess, putProcessGet. Each would have a appropriate combination of arguments and result. What about monitors? Perhaps the client could just call PVRecord.registerListener and PVField.addListener on client side implementations of a "shadow" of a record in the server.
Copyright (c) 2008 Martin R. Kraimer
Copyright (c) 2006 The University of Chicago, as Operator of Argonne
National Laboratory.
Copyright (c) 2006 Deutsches Elektronen-Synchroton,
Member of the Helmholtz Association, (DESY), HAMBURG, GERMANY.
Copyright (c) 2007 Control System Laboratory,
(COSYLAB) Ljubljana Slovenia
Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation
files (the "Software"), to deal in the Software without
restriction, including without limitation the rights to use,
copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following
conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.
________________________________________________________________________
This software is in part copyrighted by the University of Chicago (UofC)
In no event shall UofC be liable to any party for direct, indirect,
special, incidental, or consequential damages arising out of the use of
this software, its documentation, or any derivatives thereof, even if
UofC has been advised of the possibility of such damage.
UofC specifically disclaims any warranties, including, but not limited
to, the implied warranties of merchantability, fitness for a particular
purpose, and non-infringement. This software is provided on an "as is"
basis, and UofC has no obligation to provide maintenance, support,
updates, enhancements, or modifications.
________________________________________________________________________
This software is in part copyrighted by the BERLINER SPEICHERRING
GESELLSCHAFT FUER SYNCHROTRONSTRAHLUNG M.B.H. (BESSY), BERLIN, GERMANY.
In no event shall BESSY be liable to any party for direct, indirect,
special, incidental, or consequential damages arising out of the use of
this software, its documentation, or any derivatives thereof, even if
BESSY has been advised of the possibility of such damage.
BESSY specifically disclaims any warranties, including, but not limited
to, the implied warranties of merchantability, fitness for a particular
purpose, and non-infringement. This software is provided on an "as is"
basis, and BESSY has no obligation to provide maintenance, support,
updates, enhancements, or modifications.
________________________________________________________________________
This software is in part copyrighted by the Deutsches Elektronen-Synchroton,
Member of the Helmholtz Association, (DESY), HAMBURG, GERMANY.
In no event shall DESY be liable to any party for direct, indirect,
special, incidental, or consequential damages arising out of the use of
this software, its documentation, or any derivatives thereof, even if
DESY has been advised of the possibility of such damage.
DESY specifically disclaims any warranties, including, but not limited
to, the implied warranties of merchantability, fitness for a particular
purpose, and non-infringement. This software is provided on an "as is"
basis, and DESY has no obligation to provide maintenance, support,
updates, enhancements, or modifications.
________________________________________________________________________