February 28, 2010: dfe_engine revisions

This is a summary of the changes to the san_engine code in the February 28, 2010 release. The code is not under revision control, but this release is archived at https://richardhartersworld.com/test/~cri_e/archives/sancode20100228/. None-the-0less it is usable by the adventurous.

The internal structure and the interface have both been significantly altered. Some of the changes were made to make the code simpler and robust, and some were made to improve the interface. The list of changes given below probably is not complete.

1. The san_ prefix has been replaced by dfe_ in files and in the API. The rationale is that the engine is a separate entity from the proposed san language. DFE is an acronym for Data Flow Engine. The thought is that dfe_ is less misleading than san_.

2. The word “agent” has been replaced by the word “auton”. Autons are autonomous components. They are also robots in the Dr. Who program. The trouble with using agent or actor is that the terms are already in use.

3. There has been a major addition introducing portals. A portal is a pseudo auton that connects to the environment containing the nest. There are two kinds of portals, exportals and importals. An API function, dfe_create_portal, creates new portals. Birth functions for portals are part of the engine code.

   An exportal has a single inport. Its input response function moves the packet to a export queue. An API function, dfe_ctl_from_nest, extracts packets from the export queue. There are added functions for supporting the export queue.

   Importals have a single outport. An API function, dfe_ctl_to_nest, imports packets from the external environment into a nest. It accesses a table, imprec, that maps message type to importal. The current table implementation is a simple array – it will be updated in the future. When a packet is received from the environment a send command is issued for the importal.

   A test file, dfe7.c, was created for testing portal code.

4. Data transmission is in the form of packets. Currently a packet has four fields, the message type, the data/document flag, the data length, and a ptr to the data.

5. Minor fix – delete_inport calls clear_inport_queue.

6. Emissions and deliveries now both go in queues. Previously they were in stacks. The idea was that onto an emissions and then popping them off to go into the deliveries stack would make the deliveries arrive in the right order. However this did not get the right order within the import queues.

7. Created an auton categories, autcat_e. This is an enum that distinguishes between ordinary (standard) autons and special autons, e.g., importals and exportals.

8. The auton_spec struct was created. It is used for creating autons. An auton_spec struct holds ptrs to the birth and death functions, the auton category, and a label. The idea behind this is to simplify creating libraries of autons. In effect the auton_spec establishes an auton type.

9. The auton_spec label is used in sys logger messages. This makes it a lot clearer as to what is going on.

10. The get_import function was eliminated.

11. The auton_logname was created to simplify sys logging. The argument is an agent. It returns a string of the form (label).index.seqno. Many of the sys_logger formats have been reworked to use the output of auton_logname. Sys_loggers calls using auton_logname are enclosed in tests on sys.log to avoid unnecessary calls of auton_logname.

12. The exec_input function was renamed to input_response.

13. The def1 (formerly san1) test program has been expanded. It tests most of the API function and triggers most of the sys_logger messages.

14. Another test program, dfe6, has been added. It implements the prime number sieve used in the Google Go language spec.