Anyone hacking #golang code aware of any #JSON marshaller implementation that will let me have any say in what's "pretty"? The default one is waaay to spacious for anything but the most simple of objects. I can't believe I'm coming up with nothing searching for this. Kinda hoping it's just me being a boomer with no idea about how to use the internet? Please say it's so.
Oof, I'm tapping out. That bug is more like a camouflaged walking stick. I could not find what it is and where it is at.
I still learned about how the #ActivityPub protocol works, and I would like to talk about how it can be improved. When looking at a Note object, I noticed that its content property uses #HTML as the note's content. Yes, many instances have protections against the inherent risks of an XSS attack, but I'm thinking of a safer way to represent rich text that is meant to be displayed across different platforms.
What if #JSON was used instead? JSON is used by the AP protocol to represent other objects and activities, so how could JSON be used for representing UI?
Here's how some rich text could be represented in JSON:
I need some help with #powershell where we need to export some #json values all as strings. So the numbers we have in the object need to be strings, but only are exported as integers.
I have advanced the problem along a bit. My current problem is that in all my various directories of screenshot files, I have a metadata.json file I want to extract data from. I want to use the extracted data to build an appropriate "wp media import" command, to feed to WP-CLI.
Here's my dilemma: I don't know jq well enough yet. I've been trying to teach myself about how its filters work tonight, but I'm not quite comfortable enough with it or with bash to work out how to accomplish what I want to do.
I've been tasked to upgrade another inherited #drupal 9 site to 10, apply a some major updates to the existing theme, and stage it on #pantheon
As-is, none of the contrib modules had been defined in its #composer#json config, and it has quite a few complex added features and content types that may no longer be required. Let's see how this goes! 😎
JSON is usually beautifully simply and useful. I'm starting to see the same un-necessarily over-complicated nesting of simple data by API vendors as the XML crowd. All I'm missing is Base64encoded JSON inside of Base64encoded JSON.
If you're implementing DNS-over-HTTP JSON client and wondering what Accept header media type to use… 👀
There's RFC8427, "Representing DNS Messages in JSON"; it defines the JSON structure. You can ignore it. No DoH JSON API provider I tested implements it.
It also defines the application/dns+json media type, registered with IANA. You can ignore it as well. Only CloudFlare cares about the media type — and insists on application/dns-json (yes, with a "-"). 🙄
It is at this point that I noticed a lack of native supported for IRI in JVM languages. "Up the spec chain" situation was spotty; I found a couple of libs implementing parts of it. But lacking a standard representation of basic concept such as links seemed troublesome.
Isn't it fun when an API returns JSON, when there is one result, the data is a object, but if its multiple, its an array of objects. But only some calls, on other calls its always an array.
For the JSON-LD experts out there... does the Compaction algorithm ever produce a document with a null property value in the document body? I know that a null-valued property is treated as if it doesn't exist, but I can't identify the step in the Compaction algo where they are removed (given a null in the pre-compacted document). JSON-LD Playground removes the nulls, but I don't know if this is the normative behavior for all processors or not. #json-ld #activitypub
Good&Evil is a classic altrock album by Tally Hall, and now, for something completely different, JSON