[Nut-upsdev] NUT I-D (future RFC): XML encoded responses
Roger Price
roger at rogerprice.org
Thu Dec 30 16:26:41 GMT 2021
On Thu, 30 Dec 2021, Greg Troxel wrote:
>> I have received a comment asking me to add XML encoded responses from
>> the server as an option.
>
> Do you mean
>
> there is already XML and you are going to document it
>
> or
>
> there is not XML, and someone is asking to draft a description of what XML
> might be for the document, in the hopes that somebody in some NUT-compliant
> implementation will implmenent it?
The proposal is to create and document a simple XML encoding for the responses
from the Attachment Daemon, to facilitate the use of mobile Management Daemons
(clients on iPhone, Android, ...)
> As I grep the sources to 2.7.4 (yes I know that's old, but it's the most
> recent release, and what is handy in pkgsrc), I see a driver that talks XML to
> Eaton units, but I don't see a user-to-nut XML interface.
XML encoding of responses would be completely new.
>> The comment proposed REST. Is this the best choice? Would SOAP be better in
>> an RFC?
>
> Posing that question makes it clear to me that the XML situation is not baked
> enough to put in an RFC, and I think it's much better to document what's
> already established, and then after the XML has settled down, create a
> revision that includes XML also, along with any other fixes.
That's a likely path for a future RFC. A second text (which following the IETF
process, would have a new number) which corrects and extends the first and which
is carried along a standards track. But in the meantime is there a volunteer to
write text and demonstration code for the current I-D?
Roger
More information about the Nut-upsdev
mailing list