Situation:
En ce moment nos n eventsType qui sont synonyme à "je veux m'abonner aux données T tel que xyz"
et nos (environ) n eventsType qui sont des méthodes d'unsubscribe.
Problèmes:
- Beaucoup de types d'unsubscribe pour rien.
- Aucun moyen de différencier des requêtes de sync à ma connaissance. (Que se passerait-il si deux component s'étaient subscribe à CST_get de cstId:123 et qu'un d'entre eux fait appel à CST_unsubscribe avec cstId:123?)
Solution proposée:
Plutôt que d'avoir n eventsType laisser le client choisir un identifiant unique lors de sa demande de synchronisation OU générer un identifiant unique sur Kalimba. Cet identifiant unique serait unique à une synchronisation de données. On aurait juste un type appelée "UNSUBSCRIBE" qui prends en paramètre cet identifiant, peu importe le EventType de syncronisation de départ.
Situation:
En ce moment nos
neventsType qui sont synonyme à "je veux m'abonner aux données T tel que xyz"et nos (environ)
neventsType qui sont des méthodes d'unsubscribe.Problèmes:
Solution proposée:
Plutôt que d'avoir
neventsType laisser le client choisir un identifiant unique lors de sa demande de synchronisation OU générer un identifiant unique sur Kalimba. Cet identifiant unique serait unique à une synchronisation de données. On aurait juste un type appelée "UNSUBSCRIBE" qui prends en paramètre cet identifiant, peu importe le EventType de syncronisation de départ.