search for: qxflags

-----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

...D/QX_FLAG_SETVAR): to fill the command to be sent to device with data from NUT-form to device-form (so direction is NUT -> DEVICE, i.e.: write to device; answer is expected to be either 'command accepted' or 'command rejected'). So direction already depends on item_t type (i.e. qxflags). At the time the driver was written, that was enough to handle all situations. Now, I know that there can be queries that need to be preprocessed (QED<date> and the like, right?), but there's no such a thing in NUT (i.e.: you cannot pass a value to a query directly from the command lin...

...l > the command to be sent to device with data from NUT-form to > device-form (so direction is NUT -> DEVICE, i.e.: write to device; > answer is expected to be either 'command accepted' or 'command > rejected'). > So direction already depends on item_t type (i.e. qxflags). Allright, so I had a misunderstanding there. What goes in the preprocess(..) method and what is supposed to go out grinded my gears a couple of time, even after going through the code and whose documentations. More verbose documentation of the preprocess(..) [1] would be nice though. > Now, I...