Open joepio opened 3 years ago
If we use Commits as messages, the server should know which Commits it should ignore and which it should follow. How should it make this decision?
follows
arrayLet's say Users can follow things by storing a list of Resources they follow. This list should probably be a private resource that only they can access. Whenever a Commit comes in, and the Commit shares a Subject with that resource, it should be applied.
However, this still leaves new resources that could be interesting, such as new blog posts or messages.
followsParents
arrayWhen a Commit comes in that has a parent which matches one of the items in followsParents
, the commit is applied, too.
A Subscription is a resource that describes a publish-subscribe relationship between a User and some Collection.
commitEndpoint
the HTTP endpoint where commits about the thing that is being subscribed to should be posted.collection
the Resource that is being subscribed to. Can also be a collection that contains query parameters. Similar to #43 /subscribe
endpoint of the publisher, containing a URL of the Subscribe resource. /commit
endpoint of the subscriber. But how does the server of the subscriber now know if it is interested in this resource? Let's consider some solutions
/inbox
endpoint, and use the Subscription URL as a query parameter - the body will still be the Commit.
I want to be able to:
Usecases
Interesting technologies
Possible approaches
Use commits - all Commits are messages
When you want to notify some server of a change, simply send the commit there. Incoming messages or notifications are not anything special, they are simply commits.
This however does not solve filtering and following