As many of you know, I am on sabatical at CERN, working with the 2
accelerator controls groups
on joint development activities. One of the areas of development is a
common java api (application
programming interface) to their 2 accelerator control systems. For
those of you familiar with CDEV,
this is essentially addressing for java what CDEV addresses for C and
C++.
As you know, there exists a prototype implementation of CDEV in java.
Ideas from this package are
being looked at here at CERN, especially as there are many ideas in
common between CDEV and
the PS Equipment library (a C++ library, analogous to CDEV for a single
control system).
Request for Comment:
================
I would like to propose that there is a benefit in having the CERN java
api and the cdev java api be
tightly coupled, if not in fact identical. The best way to achieve this
would be some compromises
between some of the specifics of the two existing C++ api's as they are
taken into java.
Potential disadvantage #1: the CDEV C++ and CDEV Java api's would not
be identical.
Response: They are not identical anyway, as java has no pointers, and
the prototype implementation
tries, already, to have an api flavor as similar as possible to other
java packages.
Potential advantage #1: a larger user / developer community.
Specific areas where change might occur to the existing java cdev
package:
1) potential nomenclature changes:
"attributes" becomes "properties" in keeping with PS-Equip
and Java Beans nomenclature
"tag" becomes "key" in keeping with the Java Dictionary and
Hashtable usage
2) 2 new I/O functions ("get" and "set") which operate on
properties (from PS api)
(these are equivalent to the existing get and set messages, but
would allow r/w operations on
a property through a single object without string parsing)
3) increased support for dealing with arrays of similar devices
4) increased support for getting meta-data (such as string names for
bits of control registers); also:
new DeviceProperty class, with methods like isWriteable()
subclass ChoiceProperty class, with method getChoices()
5) some modifications to the Data and DataEntry classes (under
discussion)
6) new Context class, which extends Data and also fetches context
defaults from Java properties
(nice idea from Franck)
If you are interested in this topic, and have opinions in this area,
please respond to this email, and
send comments to cdev@jlab.org. You may also send to me directly as
Chip.Watson@cern.ch.
Regards,
Chip