Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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:

...

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.

...

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.

...

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

 

It may be the case that multiple providers would match this request and the caller would then merge their result streams.
However some providers do produce multiple activity sub-types

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