JSON again

[Paul Hoffman]

Greetings. I see that https://github.com/rthalley/dnspython/issues/64 has been closed again, possibly because of the lack of a single standard. For an application that I am using, I would really like a JSON representation of responses. I can craft this myself, of course, but was hoping for either something in the library or in the examples/ folder.

If nothing is forthcoming, I'm willing to do an example, but would want sanity checks done by other users.

--Paul Hoffman

[Bob Halley]

My 2021 take on this issue...

I still think that there is no good candidate for "the" JSON form, so I still don't want to freeze one.  I would be ok if we had, e.g., to_json() and from_json() methods that took a JSON "codec".  I'd be ok with shipping a few standard codecs too though I don't think I'd like to pick one as the default.  One way I've dealt with similar issues with other protocols is to have to_python() / from_python() methods that reduce things to combinations of dictionaries, lists, strings, numbers, and booleans, as the conversion to/from JSON from that is pretty easy.  I'm not really inclined to fully destructure rdata (e.g. have an MX record be {"preference": 10, "exchange": "mail.example."}) as that would involve editing all the rdata classes, whereas something that stopped at {"rdata": "10 mail.example."} is much less painful.  (Though possibly also less useful, at least for things that wanted to work with the JSON directly.  OTOH, I don't expect much code working with JSON to be doing heavy lifting on the structure of really complicated types.)  The other problem with a fully destructured generic python format is when you don't want it, as then you'd have to know how to go back into the normal DNS text format for rdata.  It would be nice if both could work, but at this point if I had to pick one I'd leave rdata in text format.

Another thing to consider is canonicalization (or not).  Should things which are equal DNS-wise but may have different representations (e.g. name being case-insensitive, generic rdata format) end up as a single JSON representation (which may lose case information) or not?  Not canonicalizing may cause issues if people store the JSON in something like mongodb.

Another thing to cope with is that JSON is UTF-8, so there can be strings which have no meaning in the DNS.  (In particular, while there is IDNA for domain names (more than one!), the isn't IDNA for zonefiles.)

If you want to move forward with this, then opening a new issue with whatever you are proposing would be the way to go.  I definitely encourage some dialog before writing code.

[Paul Hoffman]

Thanks! You've clearly thought about this. :-) I have now too, more deeply, and think that to_python() with text for rdata and text for EDNS0 results is the 90% solution here. It will JSONize just fine. I don't see much need for from_python() given that it is just a qtype and maybe some EDNS0 options, and rdata parts is a rat-hole of strong opinions. 

For now, I'll craft my own in the project I'm working on and, if it doesn't feel too icky, will propose it as an issue in the repo. If folks like it, I'll work with Bob to determine how to put it in the library in a clean fashion.

--
You received this message because you are subscribed to the Google Groups "dnspython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dnspython-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dnspython-users/077af277-064f-4499-8e48-298863b54200n%40googlegroups.com.