Thing'in provide features managing the concept of sub system. To ease the description, this concept is called cluster.
A cluster is a logical aggregate of avatars. It could for instance to gather in a same entity different avatars composing a system (e.g. a cluster 'bike' could contains wheels, chain, rims, brakes ...).
The clusters give a new level of management of avatars. Specific rights could be given to users that are identifyed as manager of the cluster over the avatars that it contains.
To manipulate the clusters, the developer should use the cluster endpoint api.
GET /cluster/
list of cluster
POST /cluster/
Create a new cluster
DELETE /cluster/avatars
Remove a bunch of Avatar from their cluster
DELETE /cluster/{uuid}
Delete a cluster from a uuid
GET /cluster/{uuid}
Retrieve a cluster from a uuid
POST /cluster/{uuid}/avatars
Add a bunch of Avatar into a cluster
DELETE /cluster/{uuid}/subs
Remove a bunch of clusters from their cluster
POST /cluster/{uuid}/subs
Add a bunch of clusters into a cluster
DELETE /cluster/{uuid}/users
Remove a bunch of Users from the given cluster
POST /cluster/{uuid}/users
Add a bunch of Managers to a cluster
Example of usage : only managers of the clusters containing an avatar A could update A. This security rule could be written in the ACL of the avatar as :
{
"condition": {"$intersect" : ["$user.clusters.managed", "$avatar.clusters"]},
"rules" : [
{
"effect" : "Allow",
"action" : "Update",
"resources": ".*"
}
]
}
Clusters could be nested (it could contain clusters). This allows designing complex systems composed of sub sytems.
Clusters could be only updated (avatar/sub cluster insertion and removing) by their managers.
Search fonctionnalities are provided over cluster concept. First through the cluster api endpoint and second through the search avatar request language (keyword $clusters).