> From: nut-upsdev-bounces+fredericbohe=eaton....@lists.alioth.debian.org [nut-upsdev-bounces+fredericbohe=eaton....@lists.alioth.debian.org] on behalf of Emilien Kia [[email protected]] > Sent: Tuesday, October 16, 2012 10:11 AM > To: [email protected] > Subject: [Nut-upsdev] About nut-scan library > > Hi all,
Hello Emilien, > > 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. Indeed, error management is a bit primitive, please provide a patch that we can review. > 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). The doc says that a nutscan_device_t structure is returned, which is right. It is the client application responsibility to handle it as needed (add it to another nutscan_device_t object, read it from the start or the end...). But you are right this may need an additional note in the 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. Are you sure there is not a difference in the mib reported ? > 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. Indeed, depending of your network, querying severals thousands of network devices might lead to some network issues. I am not sure such a regulation/limitation has to be implemented at the library level. Regards, Fred > > 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 _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
