Le Mon, 2 Jun 2014 10:23:14 +0200, Olivia Bruce <olivia.j.bruce@gmail.com> a écrit :
J'ai eu des propositions sur différents sujets que je préfère soumettre, dans ce qui suit je présente ce qui est en place et ce qui est proposé puis mon avis.
Pour la synchro: Ce qui est présent : à chaque création d'un temps ou d'une tâche, on la pousse vers le serveur puis si une modification est faite on change l'élément en base. Si l'élément n'a pas pu être poussé il est stocké puis la tentative est faite plus tard. Avantage: pas de doublon, "petite" base Désavantage: perte des données de départ au profit des modifications
Ce qui est proposé: avoir un système un peu comme des log qui va pousser un temps toutes les 5 min tant que le chrono est actif. pour les modifications il est alors ajouté un temps négatif. Avantage: tout est sauvegardé Inconvénient : volumétrie de la base, perte d'information sur le moment de la modification(début ou fin de période).
Mon avis: Les deux solutions sont équivalentes, le risque de perte des données est faible. Cependant la seconde solution peut rapidement devenir trop volumineuse.
J'aime assez l'idée de log/diff, par contre je comprends pas la problématique de volumétrie de la base : il ne s'agit que d'un fichier type texte qui conserve des lignes de log/changements. Du côté serveur, c'est interprété et retransmis dans la bdd non ? (De là, une réponse du serveur te ferait nettoyer les logs soumis?) Pour la modification, tu devrais pouvoir logguer l'evenement de façon à savoir ce qui a été changé
Pour le fonctionnement de l'application:
Ce qu'on a: L'UI est supposée fonctionner sans le module du serveur. L'UI stocke les données dans son local storage puis envoie les données vers le serveur qui stocke les données dans la base. Avantage: possibilité de fonctionner sans une connexion. Inconvénient: taille du local storage limité
Proposition : Livré l'UI packagée avec un serveur pour permettre de se passer du local Storage et utiliser directement les données du serveur. Petit plus: utilisation des websockets pour prévenir l'UI. Avantage: pas de duplication des données (local Storage/base), Désaventage: plus lourd
Mon avis: Je pense qu'il est probable que le localStorage ne puisse pas accueillir suffisamment de données. Il peut être intéressant d'utiliser la seconde idée.
L'utilisation du LocalStorage permet entre autre une utilisation plus légère, une expérience "incomplète" de l'application. Dès lors que ton UI est couplée à un serveur, le localstorage n'a en effet que peu d'utilité (sinon conserver les évènements pas encore synchronisé?) -- Yannick Martel Code Lutin <http://www.codelutin.com/> +33 2 40 50 29 28