Create RCP10

[therealbill]

An RCP to add two new sub-commands to CONFIG for better admin and issue reporting capabilities. This fulfills issue #16

[FGRibreau]

• CONFIG GETDEFAULT parameter could be a better alternative as it follows the idea behind CONFIG GET parameter IMHO
• 👍 for CONFIG DIFF though

[badboy]

CONFIG GETDEFAULT would allow for pattern matching, CONFIG GETDEFAULT * thus would be the same as CONFIG GET DEFAULTS

[therealbill]

Hmm, good points, but I don't like munging words together, especially as it confuses people when explaining or walking them through something verbally. How about CONFIG DEFAULTS instead? Then we could still do CONFIG DEFAULTS <pattern> for matching.

[itamarhaber]

Solid and helpful suggestion IMO 👍

Another direction for exploring this is to have each config entry have "fields", and then extend the CONFIG GET command with switches. Ideas for such fields could be:

• current value
• source for current (e.g. default, conf file, command line switch of the server, or runtime changes such as CONFIG SET - the latter perhaps with extended context info)
• update timestamp
• default value

The additional CONFIG GET <pattern> switches could be:

• WITHTIMESTAMP
• WITHSOURCE
• DEFAULTS
• DIFF

This would, however, require changing the RCP's gist to adding new modifiers to the existing subcommand instead of adding two new ones.

[therealbill]

@itamarhaber I initially thought about modifying the config get command. But this seems a much simpler route in terms if implementation as well as not overloading the config command. ;)

I do like the timestamp idea for determining when a value was changed. However, alternatively I'd rather see all config set calls logged complete w/values. Perhaps, if not terribly painful to implement, including the client information in the log entry. It would also be able to provide some improvement in access/config logging for those with auditing requirements. Hmm, maybe that deserves it's own RCP.