Hi all, I have started to work with the nut-scan library, to implement a little tool to generate nut configuration (https://github.com/balooloo/nut/tree/cliconf).
I have some remarks about the API, I would talk about them and having your point of view: 1- API does not provide testers to known which protocols are usable (compiled in). Indeed, there is no dedicated function to test which protocol is available (unitary protocol per protocol or globally with flags) nor return error code to inform requests fail because of lack of library. 2- About function returns, when queries (nutscan_scan_*) return NULL. The user cannot know if there is no device or if an error occurs. Perhaps errno usage or modify API to pass "nutscan_device_t*" returns by result parameter and return an error code can be a good idea. 3- Actually, returned "nutscan_device_t*" are list but there is no specification of which element of the list is pointed. In fact, it is generally the last item of the list (which is not intuitive and not specified in doc). 4- I have also see that scan functions can returns list with multiple item representing the same element (same driver/port couple, at least for NSMP). It is not a real blocker problem but it is not intuitive and not documented. 5- For possibly long time scanner with many network queries (like SNMP), the scan success result for large network ranges is conditioned to the system (/22 or /20 subnetwork). There is no policy of query execution and many can be rejected by the system. There is no documentation (just a note) about that. My 2 cents for this morning. Regards Emilien _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
