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.

Documentation (3.14/3.15)

Lots we can 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
• Data Access, other new CA-related documentation...

IOCSH Command Registration (3.14/3.15)

Add DBD file syntax to convert DBD file information into a C header file which declares the command functions (similar to how we do record types in the current code-base). This header would then be included by the C file that defines those functions, thus the C compiler would do the work of ensuring that the routine implemented actually matches the command that will call it.

The command information in the DBD file will also be useful for future versions of the IRMIS parser for st.cmd scripts, where we need to be able to tie the device support configuration commands into IRMIS' need to map hardware devices to record addresses.

PV Aliases (3.14/3.15)

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.

From Jeff: Give CAS the ability to make use of a prefix for all PV names that gets stipped before passing them to the tool. Not efficient to implement this on RSRV.

Longer strings using arrays (3.14/3.15)

Allow an array of DBF_CHAR or DBF_STRINGs to be compined in order to put a long string value into a single field that holds more than 40 characters.

Named Soft Events (3.14/3.15)

Add the ability to use an event name instead of a number in the EVNT field. EVNT is currently a short, but we only allow soft event numbers to be 8 bits, so this allows us space to add a new set of event numbers for the named events. Ideally the event names would not have to be declared in advance, although that does leave the possibility of typos causing havoc.

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 local RULES_BUILD 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)

Compiling DBD Files (3.15)

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).

Unbundling (3.15)

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.

If we adopt this, we should bundle working subsets of modules together and release the complete bundle as a tarfile.

I see the unbundled modules as follows:

Core

Depends on: Nothing

These are the common parts used by everything:

• Build system
• libCom & OSI layer
  • Basic registry routines
  • IOC shell
• Antelope
• Flex
• makeApp tool

Channel Access Client

Depends on: Core

Jeff Hill's responsibility.

• CA-specific build rules (probably none)
• CA client library
• CA Tools
• CA application makeApp templates

Channel Access Server

Depends on: Core, IOC

Jeff Hill's responsibility.

• CAS-specific build rules (probably none)
• GDD
• The CAS server tool
• RSRV (the old CA server code)
• CAS application makeApp templates

IOC

Depends on: Core, CAC, CAS

The rest is code that runs on the IOC.

• IOC-specific build rules
• Static and runtime database access
• Runtime database
• Standard record types
• Soft device support
• The registry (device, driver, record, function)
• IOC application makeApp templates

Redundancy (?)

DESY's redundant control of remote I/O, allowing hot-spare backup IOCs. No idea what this looks like, what tests are available or how easy it will be to merge.

CA Event Filtering (3.15++)

LANSCE needs Time and Flavored Data to replace ancient VAXen. Jeff's plan is to be able to attach an expression to a channel subscription, which is evaluated by the client's server thread to check each monitor event to determine whether to send it to this client or not. This could use an enhanced CALC expression parser and evaluation routine to do the expression, we just need a better parser since the expression might include record names. Discussion about how the values for the expression get saved such that they have the value at the time the data was pushed into the event queue; they might have changed since them. Jeff's fixed size event that contains those expression value resolves that issue, but it is very restrictive in terms of flexibility.

Variable Length Strings (3.15++)

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 (started, currently incomplete). This can form the basis of a new string type for use in the database in addition to the DBF_STRING.

Alternate DB File Formats (3.15++)

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.

Need to coordinate with VDCT folks, etc.

Asynchronous Gets (3.15++)

From Ben Franksen: Async dbGetLinkCallback: Needs an upgrade to the record support interface, later in the process. Or maybe include a dbGetLinkCallback() with the private callback routine, and require new record types to use this. Talk to synApps about this (Tim).

Multiple Master problem (3.15++)

From Jeff: Changes to output values in a PLC or similar device initiated outside of the output record. This could be resolved adding a new routine to the RSET that the device support calls back when it has a new raw ouptut value to back-propagate to the VAL field. Currently done by setting PACT and calling the record's process routine to use its second-half processing only. Again, talk to Tim about this.

Online Record Creation (3.16++)

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 (3.16++)

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, we don't have the shutdown facilities to allow that.