On 22/04/13 11:55, Mark Goodwin wrote:
I guess we could modify pmafm so the "replay" command used this scheme.
e.g. even though pmcollectl creates a pmafm folio, pmafm replay on
that folio fails because (a) pmafm doesn't know about pmcollectl
(easily fixed), (b) the folio doesn't have the correct comment header
(easily fixed), but (c) pmcollectl doesn't grok the standard -a archive
option .. it uses -p.
Problem (c) is a candidate to be fixed using this new scheme, but I
sort of wonder - are we promoting cmd line option inconsistencies
by fixing these kinds of problems in this way? If we were to reimplement
the sysstat suite in pcp/py, we'd sort of have no choice but to
honour the cmdline options of the original tools.
I'm aligned with Mark on this one.
We have a command line argument "standard" in PCP. We should stick to
that for all existing and any new PCP tools we create.
You can add --fluff support syntax if you wish, but this is (a) extra
and (b) not mandated ... so I am not sure of the point, independent of
my religious objections to this style of command line arguments (yes, I
am a dinosaur, but I don't think --help, rather than -\?, has ever
helped me solve a usability problem).
As to things that are re-implementations of existing tools, they should
*preserve* the syntax of the existing tools, even if the underlying
implementation is replaced by something using the PCP APIs. The really
problematic issues come when you want to expose some PCP functionality
(like replay from archives, or setting a time window, or timezone
handling, or PCP debug flags, or ...) that the original tool does not
support and these are not generally solvable, other than case-by-case
analysis that honours the original user interface of the tool and tries
to shoe-horn the new PCP command line options alongside ... this will
inevitably involve compromise and command line inconsistency, but c'est
la vie.
Adding "sub" commands to the poor old pcp(1) shell script does not feel
right to me.
|