Difference between revisions of "Future Development Ideas"

From EPICSWIKI
(Added DBE_PROPERTY task.)
 
(28 intermediate revisions by 2 users not shown)
Line 1: Line 1:
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.
These are projects that can/should be added to EPICS V3 using an evolutionary process.  The ordering is not necessarily accurate.




Line 5: Line 5:




== Tasks which could be done now ==
== Tasks for the 2014 Codeathon ==


These items can be worked on immediately as they do not depend on any other work to have been completed, and could even be included in the next 3.14 release if appropriate.
These items are of particular interest to have completed before the 3.15.0.2 release in September 2014.


<blockquote>
<blockquote>


=== Documentation (3.14/3.15) ===
=== Bug Triage and Fixing ===


Lots we can do here:
See the [https://bugs.launchpad.net/epics-base Launchpad bug tracker]. Bug
 
triage involves understanding and replicating the bug and ensuring that it still exists in the latest release. Bugs tagged 'codeathon' are especially appropriate for fixing as Codeathon projects.
<blockquote>
 
==== Record Reference Manual ====
 
* Add a chapter for the aSub record, derived from the genSub record chapter (which already exists).
* Delete the synApps record types from the R3.13 Wiki pages that don't belong there.
* Extend the DBD to HTML converter so we can move detailed record reference documentation into the record.dbd and/or record.c files.
 
==== Application Developers Guide ====
 
* Convert into an OpenDocument Text file (or some other non-proprietary format).  Machine-translating index markers is the most important part of this conversion, we don't want to lose the index.
* Write a "Building and Porting EPICS" chapter
* Restructure the AppDevGuide to make it more accessible
** Combine the libCom and libCom/osi chapters
** Maybe have a separate section for all callable APIs
** Could move all API documentation into the appropriate source files and use Doxygen or perldoc to extract.


==== Other Documents ====
=== Review Merge Proposals ===


* Look at all the documentation we have and see what's missing
The [https://code.launchpad.net/epics-base/+activereviews Launchpad active review] page lists branches which have been proposed for merging.
* Data Access, other new CA-related documentation...


</blockquote>
=== Record Reference Manual ===
 
=== ANSIfication of Base (3.14/3.15) ===


Some device support files still use K&R-style function declarations and definitions which need to be converted to ANSI standard C.
Work has started on embedding the RRM text inside the record type DBD files, but most record types have still to be documented this way. See ANJ's [https://code.launchpad.net/~anj/epics-base/dbd2html DBD To HTML branch] which contains the work done so far.


Priority: Low<br>
=== Dynamic Array Support ===
Libs affected: softDev, ...


=== vxWorks: Generate TIMEZONE from TZ ===
Neither the CAS nor the PV Gateway support the dynamic array size protocol changes that were added in 3.14.12, and it's starting to show.


The vxWorks TIMEZONE environment variable has to be set every year because it specifies the month and date of the time changes, whereas the Posix TZ variable as used by RTEMS specifies a rule to calculate those dates and is thus not specific to a particular year (as long as the rules don't change). Add code to vxWorks/osdTime.cpp to calculate the value of TIMEZONE for the current year from the rule provided in TZ. Talk to Eric Norum about this to make sure it matches what RTEMS does/uses.
=== More test programs ===


Note that you can't just put this in the timeRegister() routine since the IOC won't know what year it is until the first time provider synchronizes, and it shouldn't go in osdNTPGet() because the NTP time provider isn't guaranteed to be always running. The best way to do this is probably to define a command that calculates and updates TIMEZONE, which allows it to be added to the startup script and also run manually when needed.
There are test programs in libCom/test which cover quite a lot of the libCom functionality, but they are by far from complete.  Writing test code is a very good way to learn the capabilities of the code being tested, and is not usually hard to to, so this would be a good "getting started" project. Specific tests include:


Priority: Medium<br>
* Tests for each of the Base record types and device support. This should be based on ANJ's [https://code.launchpad.net/~epics-core/epics-base/ioc-test-module/ IOC Test Module] branch so the tests can be written in Perl.
Libs affected: libCom
* Any parts of libCom which don't currently have tests in libCom/test (C code)
* Rewrite the tests from the epics-soft-test suite (C or Perl).


=== Improve error reporting (3.14/3.15) ===
=== Convert makeBpt into Perl ===


Look at the error reporting and messages generated by various parts of the code, in particular the parsers in src/as and src/dbtools to see if their output can be improved.  The dbStatic parser was done recently so might be useful as a model, but might still be improvable.
The makeBpt tool in src/bpt generates non-linear break-point tables from data files.  A fair bit of the C code is concerned with parsing the input file.  There is no particular need for this code to be written in C, speed is not an issue, and eventually I hope to convert all programs needed for building EPICS into Perl code.  Maybe start this project by writing a program to test the output, then convert the C code into Perl.


=== Enhance the aSub record type (3.14/3.15) ===
=== Support for 64-bit integer fields ===


Allow the types and dimensions of the aSub fields A-U and VALA-VALU to be changed at runtime. This is useful to allow replacing one subroutine at runtime with another that expects different field types, or just to be able to extend an array.
ANJ has started adding support for DBF_INT64 and DBF_UINT64 types to the database, but the result has not been heavily tested and may not work on all target architectures (in particular VxWorks). See ANJ to work on this.


Priority: Low<br>
</blockquote>
Libs affected: rec.
 
=== 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 named events.  The event names should not have to be declared in advance, although that does leave the possibility of typos so maybe the IOC should be told first.  Will probably need changes to the Event record type and/or device support.
 
Priority: Low<br>
Libs affected: dbStatic, db, rec, softDev.
 
=== Timestamp on Value Change (3.14/3.15) ===
 
Be able to select whether a record's timestamp should indicate when a record last processed (current behavior), or when its value last changed.  Since the timestamp gets set by the record's process() routine, this is best done by adding a menu field to each record type, making the recGblGetTimeStamp() call conditional on that field and add another call to it inside the monitor() routine.
 
Priority: Low<br>
Libs affected: db, rec.
 
=== Rework the devLib Interface ===
 
The devLib API is not very well implemented: Some calls are redirected through a function table while others are not; the RTEMS and vxWorks implementations assume that a VMEbus is always available; PCI and its relatives are not handled at all. The API provided to devLib's clients must not change, but the API to the support code in devLibOSD.c may.
 
Note that there is an out-of-tree implementation of the devLibOSD.c file for Linux that the CLS and Australian Synchrotron use; any replacement must be able to support a plug-in library in a similar manner.  Ideally obtain and modify this implementation at the same time as changing Base.
 
Priority: Medium<br>
Libs affected: libCom/osi.
 
=== MSI flag on Links ===
 
Often records like calc read data from other records using in-links (INPA etc.). The record calculates something that has physically a different meaning than the input data. If the input data is not valid, the calculation can not deliver a valid result. So MS must be used to make this visible. On the other hand, a "high"-alarm in the source record should not alter the alarm state of the calc record. Therefore we propose to introduce a third choice: MSI = Maximize Severity Invalid. If the source record has "Invalid" severity, the severity of the local record should become INVALID (STAT=LINK), otherwise no alarm change would occur.
 
Libs affected: db, dbStatic
 
=== PHAS support for PINI ===
 
The PHAS field is currently ignored when processing records at PINI. Change the implementation of initialProcess() so it respects PHAS.  This should ''not'' be done by looping through all the PHAS values from 0 through 255. Instead:
* Look for and process all records with PHAS=0.
* While doing that, record the next highest PHAS setting used, if any.
* If a higher PHAS setting is used, repeat for that setting, etc.
 
Libs affected: misc
 
=== Additional selections for PINI ===
 
Make PINI into its own menu and add choices for RUN and PAUSE.  Modify iocPause() and iocRun() to process the records with these settings at the appropriate time (change initialProcess() to take an argument which is the PINI value that it's working on).
 
Libs affected: dbStatic, misc
 
=== ADLY and ANUM fields ===
 
Beside the alarm limits we have a "HYST" in the analog records. Why not also ADLY (alarm delay) and ANUM (alarm number). Some values are very unstable and have some noise or over-swing. So a short time over/under the limit should be allowed sometimes.  Precise meaning to be clarified, e.g: "Do not raise an alarm unless there are ANUM excursions outside HYST in ADLY seconds, or the excursion is stable for ADLY seconds."  Should ANUM=0 mean infinite?  If STAT==NO_ALARM and the alarm condition starts to change between HIGH and HIHI, what should happen? I think after ADLY seconds the alarm HIGH should be sent (the lower level if HSV < HHSV).  But what to do if the severities of changing alarms are the same?  Digital records could benefit from this mechanism although they have no HYST.
 
Libs affected: rec
 
=== Waveform record: post monitors on change using a hash ===
 
Add a field to the waveform record to hold the hash of the data buffer last posted through CA.  In the monitor() routine, calculate the hash of the current data buffer (use the new epicsMemHash() function from libCom), and only call db_post_events() if different.
 
Libs affected: rec
 
=== Analog Input Smoothing ===
 
Move the SMOO smoothing calculation out of the convert() routine so it gets used for all device support, not just those that return a raw value.  While you're doing that, move the isnan() tests out of both readValue() and convert().
 
Libs affected: rec
 
=== Attribute values for non-VAL fields ===
 
Currently most record types that have one return the EGU field contents in their get_units() routine for all fields, which is wrong for most.  EGU should apply to VAL and OVAL, plus the alarm limit fields, HYST and ADEL/MDEL etc.
 
The calc, calcout and dfanout record types have bad code in get_precision(), for their non-VAL DBF_DOUBLE fields such as ODLY it doesn't set *pprecision at all. The recGblGetPrec() routine doesn't provide the same semantics as the other recGblGetXxx() routines which makes this confusing; maybe change that or add a new routine which does (for backwards compatibility with out-of-tree record types).
 
Libs affected: rec, db?
 
=== Long strings using char arrays ===
 
MEDM and EDM already support the ability to treat a DBF_CHAR array as a string (which is not limited to 40 characters), but other CA clients including catools and the Perl CA library need to be modified to handle this.
 
Priority: Medium<br>
Libs affected: catools, extensions...
 
=== Catools and strings with spaces ===
 
Modify the catools output so strings that contain space characters (and other escapable characters?) are quoted.  The aim is that the output can be used as direct input to the caput tool.  Discuss with Ralph. See [http://www.aps.anl.gov/epics/tech-talk/2009/msg00330.php this tech-talk thread].
 
Libs affected: catools.
 
=== Database diagnostics ===
 
When an IOC is too busy to service CA the engineers need a way to find out what records are causing the problem.  Something like a dbSpy command might be helpful, which would keep a count of the records processing and give periodic reports.  Would need to be designed carefully so it doesn't eat RAM or slow down the machine too much.
 
Other diagnostics could also be added: dbProcess rate, ...
 
Priority: Medium<br>
Libs affected: db, dbStatic.


=== VDCT Enhancements ===
== Other Tasks which could be done now ==


Any Java developers want to work on these?
These items can be worked on immediately as they do not depend on any other work to have been completed.


<blockquote>
<blockquote>


==== Record info() item support ====
=== Bug Triage and Fixing ===


VDCT does not currently support record info() data in .db files. At minimum it should preserve info() items across loading and saving, and ideally it would also provide a means for them to be created and edited within the GUI.
See the [https://bugs.launchpad.net/epics-base Launchpad bug tracker]. Bug
triage involves understanding and replicating the bug and ensuring that it still exists in the latest release. Bugs tagged 'codeathon' are especially appropriate for fixing as Codeathon projects.


==== Record aliases ====
=== Review Merge Proposals ===


EPICS Base R3.14.11 will support record aliases, which VDCT does not.  Both preserving the aliases attached to a record loaded from a .db file, and providing creation and editing capabilities for them through the GUI.
The [https://code.launchpad.net/epics-base/+activereviews Launchpad active review] page lists branches which have been proposed for merging.


</blockquote>
=== Documentation ===


=== Packagable Build System ===
Lots we can do here:
 
The EPICS Build system currently does not distinguish between programs that are needed by IOC developers (e.g. dbToMenuH) and end-user programs (e.g. caget).  We could divide our build targets into these very easily, which would make packaging EPICS Base much more straight-forward.  I see the following parts:


<blockquote>
<blockquote>


==== End-user Binaries ====
==== Application Developers Guide ====


* catools
* Write a "Building and Porting EPICS" chapter
* Shared libraries
* Restructure the AppDevGuide to make it more accessible
* SoftIoc (requires compiled-in DBD data though)
** Combine the libCom and libCom/osi chapters
** Maybe have a separate section for all callable APIs
** Consider moving API documentation into the appropriate source files and using Doxygen or perldoc to extract it.


These could be installed into /usr/local from an RPM or equivalent packaging system.
==== Other Documents ====


==== Developer Tools ====
* Look at all the documentation we have and see what's missing


* flex, antelope binaries etc.
=== VxWorks SMP Support ===
* static libraries
* DBD and header files
* Build system components


These could be packaged into a -devel RPM or equivalent.
Recent versions of vxWorks (6.8+) support SMP but present a slightly different API that removes intLock() and taskLock(), and replaces taskVar with __thread variables.  The current OSD routines for vxWorks will need significant modification to work with the new APIs.  This will probably require creating a new OS-Class.


</blockquote>
Can obviously only be done by someone with access to vxWorks 6.8 or later.


Priority: R3.15<br>
=== Extended Device Support ===
This is probably a task for Janet Anderson.


=== Extended Device Support (3.15) ===
Experience converting device support layers to Extended support exposed the need to clean up the extended interface, i.e. reduce the code duplication which is currently required since the record knows nothing about the device change.
 
Converting Asyn's device support layers to Extended support exposed the need to clean up the extended interface, i.e. reduce the code duplication which is currently required since the record knows nothing about the device change.


Libs affected: db, rec.
Libs affected: db, rec.
=== JSON Parser and Generator (3.15) ===
Find or write a SAX-like parser for JSON-encoding and decoding strings.  Can't be GPL or LGPL
Libs affected: libCom
=== New Record Types ===
From Bob: Add record types - valve record, improved control records for PID and Lead/Lag (if we had a good process control guy to design the record).
Enhancements to PID should start from the most advanced implementation currently available, which is ''not'' the old PID record type from Base 3.13. There's a PID record in synApps, and there may be others available from other sites too.
Priority: Dalesio<br>
Libs affected: (external app)
=== CA support for Array with Timebase ===
From Bob: Add a new dbr_type into the channel access database - new array that includes time base and offset at least. One that also supports up to 3 dimensions (or better n).
Priority: Dalesio<br>
Libs affected: Many...


=== More flexible Access Security ===
=== More flexible Access Security ===


The AS design defines each field's security level in the record description, and limits us to only levels 0 and 1.  There are many cases where sites need finer control over access; being able to put individual fields of a specific record into a different level, and having additional static levels (use a bitmask?) would help in a number of situations. It is not clear how much work this would entail though.
The AS design defines each field's security level in the record description, and limits us to only levels 0 and 1.  Some sites may want finer control over accesses: being able to put individual fields of a specific record into a different level, and having additional static levels (use a bitmask?) would help in a number of situations. It is not clear how much work this would entail though.


Priority: Low<br>
Priority: Low<br>
Line 243: Line 104:
=== Secure CA ===
=== Secure CA ===


Secure channel access protocol - add SSL wrappers around CA to make it secure.
Secure channel access protocol - add SSL wrappers around CA's TCP connections to make them secure.


Ralph and Jeff implemented CA-over-TCP at the Codeathon in April 2008, which should form the basis of this work.
Priority: R3.15<br>
Libs affected: ca, cas, rsrv
Libs affected: ca, cas, rsrv
=== Online Record Creation ===
It might be possible to add new record instances at runtime, although delete would need a change to the record interface to support.  The tricky thing is to do this in a manner which is completely thread-safe since the pdbbase structure does not have many locks, and adding them could significantly affect operation of the IOC.
Priority: Dalesio<br>
Libs affected: dbStatic, db, misc
=== OFFLINE Alarm Status, Asyn support ===
* Add a new Alarm Status (not severity!) OFFLINE.
* Add the ability to the asyn port server to be set to OFFLINE (or use the existing "Connect" mechanism?).
* If the asyn port/address is OFFLINE, any records that make requests to it are set to INVALID:OFFLINE.
* Add any routines/tools necessary for easy administration of this (i.e. report all the OFFLINE ports/addresses).
Priority: Arnold<br>
Libs affected: dbStatic, Asyn.
</blockquote>
== Tasks which are already under way ==
These tasks are already being worked on but may have stalled.  They might be hard for someone else to take over at this stage.
<blockquote>
=== 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
=== Compiling DBD Files (3.15) ===
A Perl implementation of the DBD file parser exists and provides working dbdToRecordH and dbdToMenuH scripts. I'm working to revive my plans to convert all DBD file information into C tables that get compiled into the IOC executable or its shared libraries.
With this parser written in Perl, it is much easier to add new facilities to DBD files, such as adding new field types (see Variable Length Strings below).
Libs affected: dbStatic, +dbHost, db.
=== CA Event Rate Limiting (3.15) ===
A CA client should be able to specify a maximum event rate for each channel subscription it creates (and possibly be able to change that rate without re-subscribing).
Libs affected: ca, cas (rsrv?).
=== CA Event Filtering (3.15++) ===
LANSCE's Time and Flavored Data requirements.  It might be wise to do the Unbundling task before merging these changes.
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 the client or not.  This could use an enhanced CALC expression parser and evaluation routine to do the expression, but we need a new parser since the expression can include PV names, and the calcPerform() API may have to be enhanced to match.
Libs affected: libCom/calc, ca, cas, dbStatic?, +da, db.


</blockquote>
</blockquote>
Line 314: Line 116:
<blockquote>
<blockquote>


=== IOCSH Command Registration (3.15) ===
=== IOCSH Command Registration ===


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.
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.
Line 322: Line 124:
Libs affected: dbHost, all libs Registrar code.
Libs affected: dbHost, all libs Registrar code.


=== DBE_PROPERTY event type (3.15) ===
=== Link Support ===


Add a new CA event type which occurs whenever a property of a channel gets updated. To implement this in the database, we have to link all fields that contain property values with the fields that the property is supplied with, and have dbPut() post a monitor on those fields whenever the property value changes.
See original proposal by ANJ, which needs to be modified to add notify interfaces. This work is already under way, talk to ANJ.


Libs affected: dbHost, dbStatic, db
Part of this development (June 2016) includes [[JSON Field Values]].


=== Link Support (3.15+) ===
=== Array Field Support ===


See original proposal by ANJ, which needs to be modified to add notify interfaces.
Make it easier to add array fields to record types without having to do as much coding in the record support.  See [http://www.aps.anl.gov/epics/core-talk/2007/msg00078.php Ben Franksen email] and the work done by Nick Rees at the 2009 Codeathon.
 
=== Array Field Support (3.16++) ===
 
Make it easier to add array fields to record types without having to do as much coding in the record support.  See [http://www.aps.anl.gov/epics/core-talk/2007/msg00078.php Ben Franksen email]


Libs affected: dbHost, dbStatic, db, rec.
Libs affected: dbHost, dbStatic, db, rec.


=== Unbundling (3.15/++) ===
=== Variable Length Strings ===
 
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:


<blockquote>
The BaseString C++ APIs and classes were developed on the cvs-trunk branch and are being used by Jeff Hill in his replacement IOC server. This interface can form the basis of a new variable length string type for use in the database in addition to DBF_STRING.
 
==== 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, CAC?
 
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
 
</blockquote>
 
=== Variable Length Strings (3.15++) ===
 
3.15 already includes the BaseString C++ classes in 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 variable length string type for use in the database in addition to DBF_STRING.


Libs affected: dbHost, dbStatic, db, ...
Libs affected: dbHost, dbStatic, db, ...


=== Alternate DB File Formats (3.15++) ===
=== 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.


Need to coordinate with VDCT folks, etc.
There have been calls to be able 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 easily 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.  Alternative to XML would be JSON, for which a parser is already being included in the jsonfm branch.


Libs affected: dbHost?, dbStatic.
Libs affected: dbHost?, dbStatic.

Latest revision as of 19:51, 1 June 2016

These are projects that can/should be added to EPICS V3 using an evolutionary process. The ordering is not necessarily accurate.



Tasks for the 2014 Codeathon

These items are of particular interest to have completed before the 3.15.0.2 release in September 2014.

Bug Triage and Fixing

See the Launchpad bug tracker. Bug triage involves understanding and replicating the bug and ensuring that it still exists in the latest release. Bugs tagged 'codeathon' are especially appropriate for fixing as Codeathon projects.

Review Merge Proposals

The Launchpad active review page lists branches which have been proposed for merging.

Record Reference Manual

Work has started on embedding the RRM text inside the record type DBD files, but most record types have still to be documented this way. See ANJ's DBD To HTML branch which contains the work done so far.

Dynamic Array Support

Neither the CAS nor the PV Gateway support the dynamic array size protocol changes that were added in 3.14.12, and it's starting to show.

More test programs

There are test programs in libCom/test which cover quite a lot of the libCom functionality, but they are by far from complete. Writing test code is a very good way to learn the capabilities of the code being tested, and is not usually hard to to, so this would be a good "getting started" project. Specific tests include:

  • Tests for each of the Base record types and device support. This should be based on ANJ's IOC Test Module branch so the tests can be written in Perl.
  • Any parts of libCom which don't currently have tests in libCom/test (C code)
  • Rewrite the tests from the epics-soft-test suite (C or Perl).

Convert makeBpt into Perl

The makeBpt tool in src/bpt generates non-linear break-point tables from data files. A fair bit of the C code is concerned with parsing the input file. There is no particular need for this code to be written in C, speed is not an issue, and eventually I hope to convert all programs needed for building EPICS into Perl code. Maybe start this project by writing a program to test the output, then convert the C code into Perl.

Support for 64-bit integer fields

ANJ has started adding support for DBF_INT64 and DBF_UINT64 types to the database, but the result has not been heavily tested and may not work on all target architectures (in particular VxWorks). See ANJ to work on this.

Other Tasks which could be done now

These items can be worked on immediately as they do not depend on any other work to have been completed.

Bug Triage and Fixing

See the Launchpad bug tracker. Bug triage involves understanding and replicating the bug and ensuring that it still exists in the latest release. Bugs tagged 'codeathon' are especially appropriate for fixing as Codeathon projects.

Review Merge Proposals

The Launchpad active review page lists branches which have been proposed for merging.

Documentation

Lots we can do here:

Application Developers Guide

  • Write a "Building and Porting EPICS" chapter
  • Restructure the AppDevGuide to make it more accessible
    • Combine the libCom and libCom/osi chapters
    • Maybe have a separate section for all callable APIs
    • Consider moving API documentation into the appropriate source files and using Doxygen or perldoc to extract it.

Other Documents

  • Look at all the documentation we have and see what's missing

VxWorks SMP Support

Recent versions of vxWorks (6.8+) support SMP but present a slightly different API that removes intLock() and taskLock(), and replaces taskVar with __thread variables. The current OSD routines for vxWorks will need significant modification to work with the new APIs. This will probably require creating a new OS-Class.

Can obviously only be done by someone with access to vxWorks 6.8 or later.

Extended Device Support

Experience converting device support layers to Extended support exposed the need to clean up the extended interface, i.e. reduce the code duplication which is currently required since the record knows nothing about the device change.

Libs affected: db, rec.

More flexible Access Security

The AS design defines each field's security level in the record description, and limits us to only levels 0 and 1. Some sites may want finer control over accesses: being able to put individual fields of a specific record into a different level, and having additional static levels (use a bitmask?) would help in a number of situations. It is not clear how much work this would entail though.

Priority: Low
Libs affected: dbStatic, db, as, ...

Authentication

From Ralph: Two or three institutes need a way to password-protect access to certain databases. The usual encryption libraries are freely available, but I guess this issue needs a lot more thinking. Granularity: by record, by connection = IOC, or centralised? Should the authentication last for the client's lifetime or should a short form (some security token or key) be sent with every CA data package?

Secure CA

Secure channel access protocol - add SSL wrappers around CA's TCP connections to make them secure.

Libs affected: ca, cas, rsrv

Things which can't be completed yet

These are tasks are waiting on other people or for other tasks to be completed before they can be finished, although there may be infrastructure to support them that can be worked on in parallel.

IOCSH Command Registration

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.

Libs affected: dbHost, all libs Registrar code.

Link Support

See original proposal by ANJ, which needs to be modified to add notify interfaces. This work is already under way, talk to ANJ.

Part of this development (June 2016) includes JSON Field Values.

Array Field Support

Make it easier to add array fields to record types without having to do as much coding in the record support. See Ben Franksen email and the work done by Nick Rees at the 2009 Codeathon.

Libs affected: dbHost, dbStatic, db, rec.

Variable Length Strings

The BaseString C++ APIs and classes were developed on the cvs-trunk branch and are being used by Jeff Hill in his replacement IOC server. This interface can form the basis of a new variable length string type for use in the database in addition to DBF_STRING.

Libs affected: dbHost, dbStatic, db, ...

Alternate DB File Formats

There have been calls to be able 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 easily 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. Alternative to XML would be JSON, for which a parser is already being included in the jsonfm branch.

Libs affected: dbHost?, dbStatic.

New Record API

These requests all need a significant change to the record support API. They are also fairly closely related, so should be used as input into any new API that gets devised.

Asynchronous Gets (3.16++)

From Tim Mooney: It would be great if an input link could initiate processing, and get a value that is known to be the result of that processing, even if records to be processed are asynchronous. Currently, a record that needs completion-qualified data must know how to trigger the processing that generates that data.

From Ben Franksen: Implemented an asyncronous dbGetLinkCallback() routine. To do this properly though needs an upgrade to the record support API, but maybe could be shoe-horned into the the existing API by adding a dbGetLinkCallback() with a private callback pointer, and we'd require new record types to use this. What does this do to the device support interface though? Implications need study.

Andrew's Comment: This should be part of the implementation of linkSupport which I proposed in detail many years ago. The purpose of the "Compiling DBD Files" item above is to make extending the DBD file syntax easier to do in the future, which is a necessary part of that development.

Blocking Puts (3.16++)

From Tim Mooney: It would be nice to have a link attribute that could put, request processing, and wait for completion. We have this capability now, in dbCaPutCallback(), but it's selectable only at DCT time.

The idea is for a version of the SEQ record where rather than a fixed delay, the second link would wait for the completion callback from the first link. This should be possible today with a special record type, but Tim suggests it should be possible with any link field of any record type.

Andrew's Comment: This should be part of the implementation of linkSupport which I proposed in detail many years ago. The purpose of the "Compiling DBD Files" item above is to make extending the DBD file syntax easier to do in the future, which is a necessary part of that development.


Multiple Master problem (3.16++)

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 some devices that set PACT and call the record's process() routine to use its second-half processing only.


Records Can't Block (3.16++)

From Tim Mooney: I think almost half the code in the sscan record is devoted to bookmarking. In the middle of some algorithm, the record needs to wait for external events; the only way back in is process(), and so the record has to have a complicated arrangement of switches that get it back into the algorithm it was executing, with enough state information to decide what to do next. At the same time, the record must check to see if it's now processing because of some out-of-band request from the user. Normal and exceptional processing must, therefore, be mixed together in the switch arrangement, and adding new behaviors to the record becomes a very hairy undertaking.

But what the record would really like to do is just wait with its context intact for events, and allow special() to release it from the wait if the user has requested something that requires this. I guess this means the record should include author-defined event types in the wait mask, and special() should be able to generate author-defined events.


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.

Atomic Operations through CA (3.16++)

This is related to the Asynch Gets issue above; implement Read-Write (Swap, permits semaphores), Process-Read and Write-Process-Read (Command/Response) as atomic operations available through Channel Access.

Retrieved from "https://wiki-ext.aps.anl.gov/epics/index.php?title=Future_Development_Ideas&oldid=3813"