So I've been working on a tool that will take in a JSON-LD RDF specification (like the one here and spit out generated Go code that automatically generates the static types for it.

The intent is, ActivityStreams extensions would be able to host this specification as their @context reference, people could use this tool to auto-generate the extension for their Go code, and then build their apps with it.

Β· Web Β· 2 Β· 2 Β· 6

The intent is that the rest of the go-fed library would then be able to automatically pass-through these static types as needed (I am big on avoiding the reflection penalty, and keeping everything compile-time-safe). So folks building their federated apps in Go on top of go-fed will be able to always pick and choose which extensions to support, and always skip to the "build the app" step instead of the "roll my own ActivityPub implementation" step.

The biggest problem I am facing right now is that I am having to code into the tool the different RDF specifications:
- OWL2
So where things will get hairy is: I am lazy and don't want to implement all of them. :)

So "if" (I hope) or "when" ('cause life) a new vocabulary wants to use some esoteric RDF specification to do so, or parts of the above I haven't implemented yet, the tool will fail and the tool will need an update. Which stinks.

But at the end of the day, I want it to get to the point where if the Go code compiles, the app is guaranteed conforming to the vocabulary and extensions specification (the "data" part of ).

Then if the app happens to use the rest of the go-fed part for the actual AP behaviors, it comes with my Guarantee Seal of Approval (valued at one bagoozillitillion USD) that the "behavior" part is also to-spec. Unfortunately, a lot of that is run-time correctness.


> I am big on avoiding the reflection penalty

I wonder if this penalty is as high as having to recompile/redeploy your application every time the target API decides to add a new property to its JSON-LD representation.

It sounds a bit too "enterprisey" to me.

@mariusor If a vocabulary adds a new property and the generated go code doesn't recognize it, it just treats it like any other unknown property and transparently preserves it (requirement of ActivityPub). The only reason to recompile and redeploy is to update the app code to do something with this new field, which would require a regenerate+recompile+redeploy anyway. Reflection doesn't buy anything unless the entire app server is basically written with the reflection package types.

So how close is this tool to being done? The answer is dependent on caffeine and free time.

- [X] Can generate code from internal code data type
- [X] Can read in specification
- [~] Can turn spec into internal parse data type (in progress; difficulty: high)
- [ ] Turn internal parse data type to internal code data type (difficulty: low)
- [ ] Be able to have specifications build off one another (difficulty: unknown)

Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!

We adhere to an adapted version of the TootCat Code of Conduct and follow the Toot CafΓ© list of blocked instances. Ash is the admin and is supported by Fuzzface as a moderator.

Hosting costs are largely covered by our generous supporters on Patreon – thanks for all the help!