volatilityfoundation
Renderers: Add in very rudimentary renderer options
This allows the CLI to expose options that the renderers can offer. These options are limited (string, int, bool and bytes), so no lists or choices, etc.
Each renderer's options are also global options, meaning they're always present (although grouped). There's two ways of handling this:
a) Prefix each option with the renderer's name, duplicate options are unique b) Deduplicate options with duplicate names and prefix 'renderer'
The current choice is a) because b) might confuse people that an option which only applied to one renderer would be available for all, but comes with the inconvenience that users must adapt the option name for those that are duplicated with the same meaning.
This is at least functional and extendable in the future but still a bit clunky. We could have brought the entire configuration mechanism into play, but each renderer would require a context and a config_path and so on, meaning massive overkill and a non-addition-only API change.
This is not an urgent issue, nor one I would rush through, so I'm happy for this just to sit here and gather comments until everyone's happy with it...
@npetroni I don't want to rush this, but there is now actual call for it being present in the code. Technically the renderers only affect the CLI, even though the interfaces are part of the framework. We can move the interfaces to the CLI code and then not have to bump the version number, but I left them in there because I wanted to give people an idea of how they'd need to handle the data output, and just giving them the treegrid seemed mean... 5:P If you'd be able to review this before Wednesday then we can decided whether it makes it in before the code freeze or not... 5:)
hi, I have a question to ask whether all global args parameters should be passed to renderers so that I can get the plugin name, export directory, etc.Is this more reasonable?
Errr, tying those things together would make it more difficult to change either side of the equation later on, for any reason. It would be better to identify specifically what an output renderer may need, and then change the API so that that's passed through to the renderer. The renderers are designed to be simplistic though, and my hope was that people would come along and improve on the CLI or write web UIs that would take up the task, but that may be a while away yet...
thanks,I also know this may not be a simple thing, because there may be many things to consider.I will take a closer look.And trying to improve this.