C'est un cas d'usage intéressant, mais je n'ai rien prévu qui aille dans ce sens. À ton avis, que faudrait-il mettre en place pour répondre à ce cas d'usage ? Comment ça pourrait fonctionner ?
Je n'ai pas précisément réfléchi à ça, mais je voulais d'abord attirer votre attention, afin que vous vous preniez ce besoin en compte et j'essayais de le projeter sur votre architecture.
Toutefois, voici quelques pistes de réflexion
Il faut d'abord élaborer votre système d'ACL pour en tenir compte au niveau de l'API REST mais peut-être aussi coté backend pour plus d'efficience.
Vous définissez la notion de contexte (un peu comme les cercles google) ce qui est très bien. Vous prenez en compte la notion de données cryptées. Pensez à la notion de données anonymisées à ces fins de statistiques. Ca va au delà des "metrics" puisque c'est pour un usage "métier".
Chaque utilisateur pourrait donc décider de l'utilisation de ses données en se basant par exemple sur 4 niveaux
* privé
* restreint (géré par les contextes)
* anonyme (la donnée est accédée en lecture par des traitements mais ne peut pas être associée à l'utilisateur)
* publique
Pour l'implémentation, il me semble que des processus transverses du genre de ceux mis en place par les "metrics avec des dbs dédiées(Redis ou CouchDB) pourraient convenir.
Cependant l'usage est différent puisque ces infos seraient accessibles au niveau des applications hôte. Ceci a donc un impact sur /data
De la même manière, j'imagine que dans votre architecture actuelle un développeur d'application hôte (sauf cas serverless) doit coder une partie backend s'il doit persister des infos partageables entre points d'accès. Il devrait alors pouvoir accéder à votre système d'autorisations sans passer par l'API REST sinon ça va se ressentir sur les perfs. Il devrait donc pouvoir non seulement interroger votre API bas niveau mais aussi pouvoir collecter des données anonymisées et les persister dans ces bases dédiées. Il devra certainement être en mesure aussi de publier les services associés dans un genre d'annuaire (niveau REST et plus bas)
Autre point pour la syndication.
Si j'extrapole votre archi, un système d'annuaire distribué sera mis en place et les échanges passeront par l'API REST.
Là encore un faudra peut-être prévoir des canaux basés sur des abonnements à des événements au niveau Websocket (par exemple pour calculer les indicateurs sur des données anonymisées en agrégeant plusieurs noeuds.
Enfin dernier point, prévoir une couche d'abstraction (API bas niveau incluse) permettrait de mieux cloisonner les application hôtes, voire même d'héberger à terme d'autre langages (bon ça aurait été mieux avec du Java pour cause de JVM ;-).
[^] # Re: Donnez votre avis sur la nouvelle architecture de Cozy
Posté par El Titi . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 3.
Je n'ai pas précisément réfléchi à ça, mais je voulais d'abord attirer votre attention, afin que vous vous preniez ce besoin en compte et j'essayais de le projeter sur votre architecture.
Toutefois, voici quelques pistes de réflexion
Il faut d'abord élaborer votre système d'ACL pour en tenir compte au niveau de l'API REST mais peut-être aussi coté backend pour plus d'efficience.
Vous définissez la notion de contexte (un peu comme les cercles google) ce qui est très bien. Vous prenez en compte la notion de données cryptées. Pensez à la notion de données anonymisées à ces fins de statistiques. Ca va au delà des "metrics" puisque c'est pour un usage "métier".
Chaque utilisateur pourrait donc décider de l'utilisation de ses données en se basant par exemple sur 4 niveaux
* privé
* restreint (géré par les contextes)
* anonyme (la donnée est accédée en lecture par des traitements mais ne peut pas être associée à l'utilisateur)
* publique
Pour l'implémentation, il me semble que des processus transverses du genre de ceux mis en place par les "metrics avec des dbs dédiées(Redis ou CouchDB) pourraient convenir.
Cependant l'usage est différent puisque ces infos seraient accessibles au niveau des applications hôte. Ceci a donc un impact sur /data
De la même manière, j'imagine que dans votre architecture actuelle un développeur d'application hôte (sauf cas serverless) doit coder une partie backend s'il doit persister des infos partageables entre points d'accès. Il devrait alors pouvoir accéder à votre système d'autorisations sans passer par l'API REST sinon ça va se ressentir sur les perfs. Il devrait donc pouvoir non seulement interroger votre API bas niveau mais aussi pouvoir collecter des données anonymisées et les persister dans ces bases dédiées. Il devra certainement être en mesure aussi de publier les services associés dans un genre d'annuaire (niveau REST et plus bas)
Autre point pour la syndication.
Si j'extrapole votre archi, un système d'annuaire distribué sera mis en place et les échanges passeront par l'API REST.
Là encore un faudra peut-être prévoir des canaux basés sur des abonnements à des événements au niveau Websocket (par exemple pour calculer les indicateurs sur des données anonymisées en agrégeant plusieurs noeuds.
Enfin dernier point, prévoir une couche d'abstraction (API bas niveau incluse) permettrait de mieux cloisonner les application hôtes, voire même d'héberger à terme d'autre langages (bon ça aurait été mieux avec du Java pour cause de JVM ;-).