However, I'm not enterily happy with the "everything in
environment
variables" approach. If there is no way for the plugin to define what
it wants (parameters), the interface will expand. Just documenting it
would be ... almost wrote 'a nightmare' . Oh, did I ?
I never said "everything". Only the most basic information: like name,
version, release, epoch. 10 variables tops, with simple contents.
- Plugins are interpreted (have comments), not compiled.
A compiled plugin can also embed some info. Like in C/C++:
static const char *info = "# Name: foo\nGroup: Generic\n";
The same can be done for other compiled languages too.
- Comments for registration: What tests can I run, name, version,
info...
Comments should be optional and have some default sane values, like:
* name (default: file name),
* group (default: Generic),
* URL of guidelines (default: no URL)
* if it's a must or should check (default: should),
* list of tests it deprecates (default: empty list)
* dependencies between tests (optionally, if F-R supports them)
- Invoked with a list of tests to run + options for debug etc. Simple
CLI interface.
I assumed there would be only 1 test per file, but that could be xtended of course.
- Returns a json object as today, although it can also be an error
object.
I really don't like this point. Usually there are only 2 things to be returned:
check status and additional notes. IMO the first one should just be exit status
of the process, the second - stdout. If there are some needs, you could alternatively
return a JSON object. So you first try to parse the reply as JSON, if it fails you
assume it's plain text.
Mikolaj