.. Copyright (C) ALbert Mietus, SoftwareBeterMaken.nl; . Part of Pathways project 

===================
FEATURES (accepted)
===================

.. note:: doc-style

   The are written down as documented as if the features already is implemented. They are
   not, as long they are listed here.

Init/Config file
================

.. hint:: mostly done

During startup an init/config-file is read; when available. That file can contain global setting, that acts defaults for the parameters that are
normally set as parameter. Like: ``--gate``, ``--put``, ``--log`` and ``--vector``. (But without the dashed).

Those values override the defaults in the ATS, but are overriden by the command-line options.

There are several options
-------------------------

Syntax:
^^^^^^^
#. Use the ini-file syntax (a text file); the (default) extension is **.cfg**
#. Use a *sphinx-style* `conf.py` file (python code -- *this allows ifs and calculations*)
#. Allow both; where (IDEA) both are read, and the python setting override the ini-file one

Place/Location
^^^^^^^^^^^^^^

I) The file can be specified as parameter ``--conf path/to/file``.
   |BR|
   Then the below ones will be skipped!
#) A file with the same (base)name as the ATS-test (typical the ATS-filename), along that ATS-test
   (so the same dir).
   |BR|
   So a :term:`ATS` in the :file:`ATS/path/demo.py` can use the config of :file:`ATS/path/demo.cfg`
#) The :file:`config.cfg` file in same directory as the ATS-file. This file is only valid
   for :term:`ATS`’es in the same dir; an :term:`ATS` in a subdir will *NOT* read/use it!
#) The global file :file:`.pathways.cfg`, in the user’s home directory (:envvar:`$HOME`, or its
   windows equivalent). Alternatively, the directory to find that file can be specified in the
   environment: :envvar:`PATHWAYS_CONF_DIR`.

When several places are used, the top one override (value by value) the lower one. When the
parameter ``--conf-only`` (with a file; or by the file as set by ``--conf``) is used,
the other ones are ignored

.. todo:: Describe the config format: sections, keys and ``${key} expansion``

   The **[ATS]** section is used (and, the default section)

.. note:: No ATS/shared.cfg
   The idea to have a :file:`shared.cfg` file in the :file:`ATS/` directory is abandoned.

   This ATS-dir (or “top dir”) is only a naming convention; there is no way to calculate (find)
   it. It has to be specified; but then, it is useless, not better then using a
   ``--conf``. option

   Use ‘:envvar:`$HOME`/:file:`.pathways`’  option instead




Auto run ATS
============

.. todo:: AutoRun ATS_* (Need details)

All ATS-test-functions should have a name that start with ``ATS_``; (not `main` as it used to
be).

Then, those tests can be runs automatically (in alphabetic order, by dir/subb/file/func-hierarchy)


Pre/Post
========

.. todo::  Specify Pre/Post (setup/teardown)

It should be possible to run some code before and after each ATS.

Example: the code in :program:`examples/calculators/server/tst/connect_test.py` shouldn’t be in a
shell-script but (impliciet) in an ATS


split/make package workshop, etc
================================

Currently, all of Pathways is one bug *development structure*. That is too complicated for a
workshop. So it has to spilt, or better: ‘distributed’ differently.

Probably the best way is to use make/makefiles to do that; possible some file has to move around

A. Make an installable pathways package (more or less the pathways-dir)
#. Make a --or a few-- small workshop bundle(s). Both in demo mode and/or practice mode.
   In ‘demo-mode’ has all (needed) files; in practice-mode, you have make ATS/brick yourself; or
   extend them
#. Documentation; mainly: not in package, nor in WS-bundle. Possible WS and full 


GATE/PUT
=========

GATE vs PUTS
------------

The :term:`put`, the product under test, is typically an *address* to reach a (one?) thing; the
:term:`gate` is *code* that abstracts the gate from generic Pathways-code.

So, it kind of wrong the baseclass for the “gate” is “:class:`~pathways.puts.put.Put`”; as are all
current subclasses. This should be renamed!


Config
======

.. _bug-cfgput:

Put/gate & :class:`pathways.core.config.Config`
-----------------------------------------------

A gate (plugin) should be able to use the config values. This is a feature, but also bug (alike)

E.g the webPut should use a BIN_PATH value to locate the ``geckodriver``

Cmdline gate
------------

.. todo: Create generic commandline gate

MultiHead Gate/Put
------------------

In some cases, it would be very nice to have a gate/put with 2 (or more heads). Eg. to test a
(MQTT, DDS, ...) channel. Both for functionality and performance.