Open nedjo opened 4 years ago
Spent some time looking over the options here. The model that stands out is JSON:API. The authors of that module have already tackled many of the hard questions we'll face here. While we won't need nearly all of what's there, we can draw a lot.
A key design feature of JSON:API - and a difference from our use case - is it "just works". While there's a lot of tweaking you could do, there aren't any necessary choices in exposing data for the JSON:API spec, so it's possible to have a default implementation that you just turn on. Only if you need changes do you then need to alter the defaults, which you can do either programmatically - like by writing custom normalizers - or via the config entity and accompanying UI provided by JSON:API Extras.
In our case, we're not just exposing our data; we have to also map it to the specific object types and properties expected in the AP spec. So "it just works" isn't a realistic goal. We need a configuration entity and UI. However, with some tweaks, the basic architecture of JSON:API is still applicable. Because our task is fundamentally similar. Like JSON:API, we:
So like JSON:API we need a solution that's automatically aware of all such.
Following ResourceTypeRepository
, we compile a repository of all content entity types and their bundles and fields. This repository does not include mappings, either to AP object types or their properties. That's done via a configuration entity type, parallel to that defined by JSON:API Extras, with the difference that it's defined by our base module. Then the admin UI for working with these config entities is in a dedicated UI module. (This part of the solution is closely parallel to core's RDF module and the contrib RDF UI.)
The admin UI looks a lot like that for JSON:API Extras, with the following differences:
comment--comment
, but provide the entity type label ("Comment").Ah I guess I mixed a bit of this with #6 (sorry). But as I was verbosely talking about there the RDF helps here because it is namespaced linked data, and can even include the schema.org NS properties.
Each Drupal content entity bundle (node type, media type, etc.) can be mapped to a specific Activity Streams object type.
Notes:
types: ''schema:Article'
on a content type would map to theArticle
ActivityPub object type; possibly,a field with
properties:'schema:text'
would map to thecontent
property in ActivityStreams.Event
.media
entity bundle) using theVideoFile
source plugin maps to theVideo
object type.startTime
. But note that the same field might map also toendTime
and evenduration
.$node->updated
should map to theupdated
property.\Drupal\Core\TypedData\DataDefinitionInterface::isInternal()
.Possible models
There are many ways this could work.
Relevant models include:
Core RDF module plus contrib [RDF UI]().
Configuring a content type:
Configuring a content type's fields:
Core JSON:API module plus contrib JSON:API Extras
Selecting which resources to override:
Configuring properties and fields:
Group module
A plugin for each entity bundle that can be enabled for a group:
Configuration for a plugin: