search for: preprocess_answer

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

mmh.. At the moment there are 3 distinct preprocess functions that operate on 2 different types: - info_rw_t - preprocess(); - item_t - preprocess(); - item_t - preprocess_answer(). For info_rw_t: range/enum values are preprocessed just to see if that specific value is to be used or not depending on the conditions the driver meets at runtime (e.g.: low voltage devices -> low voltage ranges). So, in this case, directions don't seem to make sense to me. For item_t: -...

...c day requested from higher layers (such as the client). On 19/05/15 02:11, hyouko at gmail.com wrote: > mmh.. > > At the moment there are 3 distinct preprocess functions that operate > on 2 different types: > - info_rw_t - preprocess(); > - item_t - preprocess(); > - item_t - preprocess_answer(). > > For info_rw_t: range/enum values are preprocessed just to see if that > specific value is to be used or not depending on the conditions the > driver meets at runtime (e.g.: low voltage devices -> low voltage > ranges). So, in this case, directions don't seem to make sen...