The refactoring is more complicated than it sounds. The file activitypub.py
was created by merging two sets of views from the old bowler_heavy
branch. This resulted in two classes called InboxView, and of course
the second one in the file won out. I have merged them and fixed
the errors therein.
As part of this, I have discovered that d-r-f adds the requirement
that view methods return HttpResponse objects. Therefore we've had
to add a new class, ActivityResponse, whose only purpose is to
get around this requirement.
fetch() has been updated as appropriate.
This is a bit complicated. We used to have two functions called
create_local_person(): one of them was in bowler_pub and the other
was in trilby_api. The bowler_pub one worked better because it
defaulted to using test keys rather than expecting the system
to make new ones, which is slow and wasteful.
Therefore, we have moved the c_l_p() from bowler into trilby,
and thrown the trilby one out.
While we're at it, we have also moved create_local_status and
create_local_like from bowler into trilby, and deleted trilby's
create_local_note.
This makes everything faster and easier.
On a LocalPerson, our own models are the authoritative source for their followers.
On a RemotePerson, we have to grab the list from the remote server.
I've made some tests for the LocalPerson part, but the RemotePerson part
still needs testing. This has involved creating a test_person module
in trilby, because test_account is for integration tests.
Tests for local delivery added. These tests don't yet check the results. When they do, they will fail because of
issue #37.
No tests for remote delivery yet. They're coming soon.
This is for consistency with "inbox" for RemotePerson, which is merely the URL.
At some point it will need to be "get_inbox_collection", but that will
make it visible via ActivityPub and we need to make sure permissions are checked.
being an object, not a string. This was a regression.
Tests updated. Thanks to vpzom for catching this.
Also, the same representation's "endpoints" object is now generated
on the fly. This means that changes to the TESTSERVER variable
during testing are correctly represented.
It uses threading.excepthook, which doesn't exist in pre-3.8 Python. But there's no need to break all the tests under 3.6.
suppress_thread_exceptions was introduced in commit 001698cd.
There is one difference, which I think isn't important in the circumstances.
If lookup() is asked about a remote person that we don't already know about,
it either creates a blank record for them and returns it, or raises an error.
In these circumstances, fetch() will perform a lookup and populate the record
accordingly.
local_form() and remote_form() class methods. This is to
allow fetch() to check whether something is already cached
before fetching it.
LocalPerson also gains a status() method for symmetry with
RemotePerson; it always returns 200.
Tests updated.
This regressed in commit a2a790f1. Before then, handlers could be defined for particular object types.
When we moved to general-case handlers for each Activity type, we should have added object type checks
to replace the checks implicit in the type-specific handlers.
fetch() used to allow handlers to specialise for Activity and object type,
like on_announce_note. But we don't always know the type of the
"object" field when we receive it, because we might only have its
address. Therefore, handlers can now only be named by the Activity.
on_announce now passes the simple tests.