[Nut-upsdev] NUT I-D (future RFC): XML encoded responses

[Jim Klimov]

One sort of benefit to XML is indeed a schema (but there are json-schema
efforts out there), so data can be validated, expected, generated... and
commented (unlike standard JSON).

We had some precedent set by integration for XML parsing (with libneon that
is already tied to NUT codebase for older Eaton NetXML devices), in the DMF
branch and more so in 42ity fork, to load data mappings at run-time instead
of precompiling tables into binaries like snmp-ups. Recipes there include
xsd validation of generated mapping files (helping find bugs sometimes).

Not volunteering to create a NutXML protocol, just highlighting
"low-hanging fruit" for implementation.

Jim

On Thu, Dec 30, 2021, 17:26 Roger Price <roger at rogerprice.org> wrote:

> 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
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20211230/97fbe377/attachment-0001.htm>