[Nut-upsdev] NUT namespace: RFC for new variable addition

[Arnaud Quette]

Hi Charles

thanks for your comments first, and sorry for still being missing on the
list.
I'm still caught in the storm of my personal issues, and the overload at
work...

2017-08-04 13:34 GMT+02:00 Charles Lepple <clepple at gmail.com>:

> On Aug 4, 2017, at 3:00 AM, Arnaud Quette <arnaud.quette at gmail.com> wrote:
> >
> > Comments and feedback warmly welcome.
> > Please however note that I'll be pushing the related commit, since it
> seem trivial.
>
> It does sound trivial, but do we have that sort of information for other
> PDUs, and if not, how should names be represented in a GUI if
> outlet.n.name isn't present?
>

outlet.n.desc is a good fallback.
I should also probably clarify in the namespace the .desc can be modified
by the user while .name is static, and (potentially) related to some
physical labelling.


> Also, there were some dstate changes a while back, and I didn't fully
> understand the need for them. Weren't they related to the volume of updates
> for PDUs? Is that more related to the total number of bytes, or number of
> variables? Should we be looking at alternate ways to represent updates,
> since the outlet names and descriptions will change so infrequently
> compared to other variables?


you're probably referring to the "synchronous" option which is needed not
to flood the unix socket:
https://github.com/networkupstools/nut/commit/924f69c65cbf3b0a6e975d3a1efef06898f97f36
https://github.com/networkupstools/nut/commit/eb64b76cfda5e30c8c1363c5fe72f989d086c9e0

it's really tied to the volume of bytes pushed through the socket.
I never had time to get back on this, but we may be able to overcome this
more cleanly through getsockopt() / setsockopt(). Then the question would
be "which value to set?"

cheers,
Arno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20170823/b42eaea4/attachment.html>