[Nut-upsdev] About nut-scan library

[FredericBohe at Eaton.com]

> From: nut-upsdev-bounces+fredericbohe=eaton.com at lists.alioth.debian.org [nut-upsdev-bounces+fredericbohe=eaton.com at lists.alioth.debian.org] on behalf of Emilien Kia [kiae.dev at gmail.com]
> Sent: Tuesday, October 16, 2012 10:11 AM
> To: nut-upsdev at lists.alioth.debian.org
> 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
Nut-upsdev at lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev