Goal:
Reduce disparities between the configuration objects that initialize similar providers from various data sources.
Problem:
Every provider requires a configuration object directing it what data to produce. The schemas for each type of provider are different.
There is some commonality on configuration objects from the provider module, but little to no commonality across data from different provider modules, even when the type of normalized data produced (verb type, object type) are the same.
Context:
Providers generally produce just one type of data:
a) Either activities or activityobjects
b) Generally just one or several activity or activityobject subtypes
After normalization to activity streams, data is intended to be similar.
Example:
Twitter User converts to Activity Streams Page, and Instagram User converts to Activity Streams Page
Twitter Tweet converts to Activity Streams Post, and Instagram Media converts to Activity Streams Post
Solution:
It should be possible in theory to direct a provider in terms of the output desired, rather than in terms of the parameters needed to produce that output.
a) determine which is the appropriate provider to produce the desired
b) run that provider using the details in the universal configuration primary
c) retaining a way to supply provider specific parameters as well, but attempt to consolidate whatever we can.
Note that the data available from the upstream system is likely to be constrained based on the permissions of the available authenticated connection.
The details of how to connect to the upstream system should be cleanly separated from the configuration of what is desired from a provider instance.
Each provider instance should try to produce what is being requested, if it believes it might be able to, and if it cannot for whatever reason, produce an empty collection.
Scheme:
The generic scheme proposed would be a java bean / json payload taking the shape of either a generic Activity or generic ActivityObject.
Any fields populated should be interpreted as a constraint on what data is desired.
If the request contains an 'objectType' field, the implementing provider should produce a collection of ActivityObject of the type specified.
If the request contains a 'verb' field, the implementing provider should produce a collection of Activity of the type specified.
If "objectType": "*" that indicates the caller is interested in getting ActivityObjects with any objectType
If "verb": "*" that indicates the caller is interested in getting Activities with any verb
Some Basic Examples:
All pages available (may be too generic to be fulfilled)
{
"objectType": "page"
}
In this case the outputs are streams-normalized Page activityobjects
All notes available (may be too generic to be fulfilled)
{
"verb": "note",
}
In this case the outputs are streams-normalized Note activities
All posts by an actor, identified by id
{
"actor": {
"id": "id:twitter:12345"
},
"verb": "post"
}
In this case the outputs are streams-normalized Post activities
All posts by an actor, identified by handle
{
"actor": {
"handle": "screenname"
},
"verb": "post"
}
In this case the outputs are streams-normalized Post activities
All posts or shares by an actor, identified by handle
{
"actor": {
"handle": "screenname"
},
"verb": "*"
}
In this case the outputs may be streams-normalized Post or Share activities
All shares by an actor
{
"actor": {
"id": "id:twitter:12345"
},
"verb": "share"
}
In this case the outputs are streams-normalized Share activities
All shares of a post, identified by id
{
"verb": "share",
"object": {
"id": "id:twitter:post:5252352353"
}
}
In this case the outputs are streams-normalized Post activities
All follows of someone, identified by id
{
"object": {
"id": "id:twitter:12345"
},
"verb": "follow"
}
In this case the outputs are streams-normalized Follow activities
All friends of someone, identified by id
{
"actor": {
"id": "id:twitter:12345"
},
"verb": "follow"
}
In this case the outputs are streams-normalized Follow activities