Tests cover the usual plus the major points:
- Updating top-level fields in object
- Updating multiple objects at once
- Removing values that are a null literal in JSON
- Remove sub-fields of objects; this may not be to spec (pending
response from https://github.com/w3c/activitypub/issues/303)
Don't drink and stay up late at night trying to solve nasty problems,
one just might decide writing a from-scratch JSON parser is the right
thing to do. Instead of diving into nuances of existing solutions within
the standard library and leveraging those.
I am only committing this to history so that I can immediately delete it
afterwards. As insurance against anyone trying to glorify this work
as the product of some genius, I can point to this and say "yeah, some
genius this guy is".
Saturday-morning coffee-drinking me is laughing at Friday-night
beer-drinking me.
Note that if this project gets serious I won't pollute the git history
like this. But as the project is young enough that most won't care about
this early history, I feel like enshrining some self-deprecating humor
into deep history is OK.
Fix normalizing the recipents between the object and the activity. Also
allow the handlers to adjust what gets placed in the outbox, since the
client-to-server API allows the server to modify the object before being
delivered.
Also move some functions out of the generic Application interface into
the specialized SocialApp interface. They will be moved back into the
Application interface if further development needs it when implementing
inbox forwarding, for example.
Also refactored the likes/liked add-to-collections logic so that they
are also applicable for following and followers collections. This code
is still as ugly as sin.
Before more tests are to be written, the delivererPool concept needs to
be fully divorced out of the fed library. It is a detail that is
tangential but supplementary. Right now though it is complicating the
tests due to its asynchronous & complex nature. Breaking it out
will simplify the ~90 tests remaining that capture the more nuanced
behavior of this implementation.
This was uncovered during writing tests where both the Social and
Federative APIs are enabled. The actorObject interface was overused
partially due to my earlier confusion; the introduction of the internal
actor interface resolved this.
Finally, the HttpClient interface was introduced to be able to mock out
calls in testing. It may also prove useful for future applications using
this library.
There's another iteration of design that can be done that moves
management of actors and collections back into this library, as right
now a lot of the Receiver interfaces put that burden on client
implementations.
Cory Slep