search for: preprocess_command

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I would like to propose an interface change/extension, in order to be able to clearly differ from a PRE_SEND and a POST_RECEIVE item_t->preprocess-ing calls. IMHO there is no option to differ from item->preprocess(..), called from [1] and called from [2], at the moment. My idea is to extend the item_t->preprocess(..) with an additional

...nd, you may need both the NUT->device and device->NUT preprocess functions and I don't feel enthusiastic about having big functions that switch on direction - I already see myself lost trying to get out of it. What I'd do instead is to add a 3rd item_t preprocess function (be it 'preprocess_command()') that works like the preprocess_answer() one (but in the opposite direction): this function would be called just before the command (any command, both queries and instant commands/setvars, no difference) would be sent to the device so that: - queries that need to be preprocessed, can be; - d...

...further. But thats just me. There's a lot of potential beautifying in the item_t structure (e.g. moving all the dynamic data a sub structure leaving a single dynamic field, building preprocessor wrappers). > What I'd do instead is to add a 3rd item_t preprocess function (be it > 'preprocess_command()') that works like the preprocess_answer() one > (but in the opposite direction): this function would be called just > before the command (any command, both queries and instant > commands/setvars, no difference) would be sent to the device so that: > - queries that need to be prepr...