Okay, my parser now (correctly) works with objects from #mastodon, #firefish, and #bovine and covers all of AS2, JSON-LD context objects, and a few actor-specific extensions from Mastodon specifically.
I also implemented some (thread safe) caching so as to not annoy myself later.
There's a lot of spit-and-polish still required and a bunch of tests still to write to explore all of the corner cases, but I can call that good for now and move on to something else for a bit.
Big thanks to @helge for providing a bunch of valid test cases. I'm using only a fraction of a fraction of it (and funfedi.dev) for now, but it's been a great resource in getting all of those pieces set up and validated.
I definitely want to implement the (ubiquitous) security extensions and the vcard extensions, but that can wait until I have actually more of the system working around it.
I receive the object and I cheat in how I deserialize it into a POJO: First I create a JsonObject and then I scan that object to figure out what kind of type it is.
Then I build an interface set out of a set of mixins (interfaces with a bunch of default methods on them)
I then take my best guess if I don't recognize anything and then modify based on properties that I (heuristically) find. Does it have a context? Does it have an inbox and an outbox? etc.
Then I take that and create a dynamic proxy based on my set of interfaces and back it with a record that contains the JsonObject and some metadata.
The proxy directs calls to the default methods to the default methods, and the calls from the default methods to get the relevant information to the base object.
Each default method then calls back into the deserializer to deserialize the appropriate return type. Whatever that may be. Basically repeating the process.
In the future I will make this a little more heavily annotation based so that there's a little less boilerplate and better performance. I can also explore generation, though every attempt I've had in that regard so far has failed on some corner case or another there are a few avenues I haven't approached yet.
I also put a cache into the dynamic proxy so that repeated calls to the same method don't end up building the same (functionally immutable) objects again and again and again.
This is not the end of the road for the parsing journey, but it does feel like a solid step.
From here I can take it and more easily build the intermediate forms I ultimately want to work with and which are less painful for the downstream systems to handle.
So it's minor in most ways and a small part of the overall architecture/journey, but it's also an important step to getting the full thing put together and I'm glad to finally have a working pattern that I can prove works.
@Pxtl I mean I think I might have, without realizing it or ever having looked at the gson source code, reinvented the way that gson does parsing already (but on top of gson and specifically supporting the AP use cases) 🤷🏻♀️
But yeah, 500 ns to load an object lazily: not the end of the world.
1+ ms on a database query to do it? Possibly not what you want to be doing.
Add comment