Nut upsdev - Oct 2012 - About nut-scan library

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

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