Citeren Marco Chiappero <[email protected]>:

Ok, I clearly see your point now, the NSM would not follow this design rule, however it could be an acceptable solution, requiring not much code and no modification at all to the current structure.

It's not a design rule, its how the socket protocol works. One connection, one driver, one UPS (outlet). This is the base of the system and *any* changes there have impact on *all* systems (not only the netxml-ups driver). At the moment we have bigger things to work on.

Sure, but a single driver could contain all the (vendor) specific logic without tainting the upsd code (starting from a netxml-ups clone and my patch).

Your proposed changes to the netxml-ups driver can only monitor a single UPS for the above mentioned reason. The socket protocol between driver and server can only handle one UPS, not multiple ones (which would be essential to even consider including). The problem with the NSM stuff is, that this requires exclusive access to a socket on the machine the driver (and as a consequence, the server) is running on. This is a problem and I really see no easy solution to that.

On the other side I think that, discarding the separated driver solution, it could still sound reasonable to provide a NSM in the mge-xml subdriver for the moment, even though currently it is useful on small setups only. Isn't it?

Not in the netxml-ups (or mge-xml subdriver). Given the above difficulties, this *must* be a separate driver, because we already have production systems that would break if this was added. I would consider a NSM driver only, but without the parsing of additional XML data from the UPS. It should only parse the ALARM messages, nothing more. For logging purposes, one would then have to run a SNMP or XML enabled driver on the side and use the NSM one to shutdown attached clients.

Best regards, Arjen
--
Please keep list traffic on the list


_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev

Reply via email to