Future Development Ideas

These are my notes for what I think we can/should add to V3 through an evolutionary process. The ordering is probably vaguely right, but not necessarily that accurate.

3.14 Changes in progress

The following modifications are currently under way in the 3.14 branch. They will probably be included in a R3.14.9 release, timescale TBD.

• Add epicsUnitTest routines to libCom which generate output in the Test Anything Protocol (TAP) format.
• Convert the existing test programs in libCom/test to use epicsUnitTest routines, which automates these tests.
• Major overhaul of the calc expression parser with improved diagnostics and additional functionality.
• Enhancements to the Access Security parser to improve diagnostics.
• Support for 64-bit CPUs (solaris-sparc64, linux-x86_64).

3.14 Changes needed "soon"

• Full GDD support for alarm acknowledgements, or whatever changes the PV Gateway actually needs to properly support the alarm handler.

3.15 Cleanup

3.15 already includes the Up change to the build system; the ramifications of this change have not been followed up completely though:

• Provide a perl script for converting 3.14 apps to 3.15
• Bring over latest templates from 3.14
• Implications for building extensions not worked out
• makeBaseExt.pl is probably no longer needed
• Install RULES files into a top level directory
  • Use this dir instead of the configure/O.arch directories so that a make clean doesn't remove them...
• Change script installation rules (see ctlsys)
• Version numbering - switch from alpha/beta to release candidates RC1 etc. which probably needs some change to CONFIG_BASE_VERSION

Documentation

Lots to do here:

• Write a "Building EPICS" guide (chapter in AppDevGuide?)
• Restructure the AppDevGuide to make it more accessible
• Convert AppDevGuide into an OpenDocument Text file (keeping index markers)
• Update the Record Reference Manual to 3.14 and beyond (generate tables automatically from DBD files?)
• Look at all the documentation we have and see what's missing

Compiling DBD Files

My Perl implementation of the DBD file parser is still in process, and I'm hoping to revive this development effort to convert all DBD file information into C tables that get compiled into the IOC executable.

With this parser now being written in Perl, it will become easier to extend the new facilities that we implement, such as adding new field types (see Variable Length Strings below).

PV Aliases

The ability to add aliases to existing records has already been demonstrated and is a desirable feature, although the implementation that goes into Base might be somewhat different.

Unbundling

Split Base into three or more independent modules. Each module would have its own version number, and the modules can therefore each have an independent existance, although there would obviously be specific dependencies associated with particular versions. I see the modules as follows:

Core

These are the common parts used by everything:

• Build system
• OSI layer
• libCom
• Antelope
• Flex
• makeApp tool

Channel Access

These are Jeff Hill's responsibility. He may want to further unbundle GDD and CAS, which is up to him.

• CA-specific build rules (probably none)
• CA client library
• CA Tools
• GDD
• The CAS server tool
• CA and CAS application makeApp templates

IOC

The rest is code that runs on the IOC.

• IOC-specific build rules
• Static and runtime database access
• Runtime database
• RSRV (the old CA server code)
• Standard record types
• Soft device support
• The registry
• IOC shell
• IOC application makeApp templates

Redundancy

DESY funded project for Bob & John to add redundant control of remote I/O, allowing hot-spare backup IOCs.

CA Event Filtering

LANSCE wants Time and Flavored Data. I think this should be implemented differently to how Jeff is currently planning, with my design involving much simpler changes to the core code but requiring a bit more applications work from the LANL software guys. The following describes my ideas, which Jeff doesn't agree with:

The main change would be to allow a CA client to subscribe to monitors on a channel but include another CHID in the subscription giving a channel that controls whether an individual event would be sent to that client or not. The conditional channel would give a boolean value, which would be checked every time a monitor event is notified to the server; if true the server sends it to this client, if false it doesn't. Initially that channel would have to be on the same IOC as the main channel, but if Jeff wants to implement a suitable CA client in the server that restriction could be removed.

To implement the Time and Flavored Data that they want LANSCE would have to create records (or record fields) in the IOCs that become true when their events are occurring and false otherwise. A client that wants to configure a non-standard flavor might have to ask a central facility to allocate and set up an appropriate calc record on its behalf.

The major advantage of this approach is that it only needs changes in the CA server and client code; there are no modifications needed to the database, record or device support layers at all. Other sites will be able to make use of the new CA facility as well, whereas Jeff's original requirement was very LANL-specific and would be unlikely to be used much elsewhere.

Variable Length Strings

I'm already adding my new BaseString C++ classes to libCom, and I intend to create a set of C wrapper routines for the base class operations. This can form the basis of a new string type for use in the database.

Alternate DB File Formats

There are calls to replace the existing DB file format with an XML-based format. Currently the DB file parser is too highly integrated into the process of record creation to be able to add a second format, but it would be feasible to separate these two and hence allow an expat-based or similar parser to be written. This would probably require a close analysis and upgrade to the locking arrangements of the database.

Online Record Creation

With good database locking, it might be feasible to look at the ability to add new record instances at runtime, and maybe delete as well. This would probably need a change to the record interface to initialize the new instances.

Dynamically Loaded Modules

After converting the DBD load process into table registration, it should become easier to allow support modules (containing record types, device support and other drivers) to be discovered and loaded dynamically. Unloading is a very different matter though.