[Contents] [TitleIndex] [WordIndex

1. Improving / simplifying module making : Discussions

PAA: Pierre-Aimé AGNEL
SG : Samuel GOUGEON

1.1. tbx_config()

SG:
OK: Creating from scratch the files structure of a new toolbox may be seen as its first configuration step. Therefore, this operation may be usefully supported through the same tbx_config() function that will be used to set and update the toolbox parameters afterwards.
Alternately, creating a specific tbx_init() to do this step does not look useful. If after implementing and using tbx_config("init") we see that splitting this in a dedicated public function would be better, we will do it. Most of/all these toolboxes operations are done by hand in a console-oriented way. So BC issues are not really a concern.

SG:
Proposal (about the presentation): Switch the order parts

PAA:
OK: I switch the requirements number and position, and add the subsections

1.1.1. tbx_config("init")

About the proposal:

tbx_config("init") // creates a default layout with macros/, help/ and tests/ folder and a license.txt
tbx_config("init", "default") // same as above
tbx_config("init", "code") // adds the src/ includes/ and sci_gateway/ directories
tbx_config("init", "xcos") // adds the default mandatory xcos directories
tbx_config("init", "all") // all possible directories as taken from the skeleton

SG:
Comments:

PAA:

About initial files:
SG:

PAA:
I agree with a management of licenses. It is my strong opinion that the ATOMS server should only manage open source code and Scilab Enterprises should manage a separate channel/service for nonfree code. For the function though a selection of licenses should be proposed.

1.1.2. Name and format of the config file

SG:

PAA:

SG:

PAA: etc/ should really be extra configuration for user specific purposes, I tend to agree with you on removing the requirements (and files) from etc

1.1.3. Local GUI and ATOMS server

SG:

PAA:
 * My suggestion here is to open a web browser page and have the ATOMS portal manage the GUI for the settings. This will avoid code duplication inside scilab. The server will have a scilab that will create the config.ini file and send it back to the user. This has many advantages:
    1) the server can check immediately if other toolboxes with the same name exists
    2) the server can give the list of versions for a toolbox
    3) the edition possibilities of a web based application is greater and more easily maintained than those of a local GUI
    4) the management of mandatory fields will be easier on the web page 

 * The validation on the web page will lead to an upload of the config.ini file.

 * Local GUI: Alternately, the GUI could be entirely Scilab based but this will imply more maintenance and should not be preferred, but alleviate the need for an internet connection or a private ATOMS server

SG: I have no sharp opinion there. May be i would rather prefer editing all parameters locally, recording them in the config file. Then, through the tbx_publish(),

PAA:
My real concern here is duplicating the GUI. There exists a configuration page already, it's the ATOMS server web page. It does already all the necessary verifications (unicity, versions, dependencies). The only improvement it could have is creating the config file (instead of a text description) ready for upload, which would remove the need for the atomsDESCRIPTIONread() function (that takes most of the processing time in ATOMS btw just to recreate a structure that could be computed once on server side and loaded directly in scilab).

SG:

PAA:
The tbx_config could very well be the opening of the ATOMS webpage for DESCRIPTION, once filed sends back the config.ini file. tbx_publish should be a button/action in the filebrowser really :) ( => publish in atoms, => publish in fileexchange )

1.1.4. Supported parameters

The list may be discussed later.

1.2. tbx_make()

Remarks and questions:

PAA:
BC is really an issue here, tbx_make should keep building former toolboxes, but slowly deprecating the numerous helper functions is the right direction (eventually there would only be a tbx_config, tbx_make and tbx_publish high level functions.

PAA: you are right

1.3. tbx_publish()


2022-09-08 09:27