|
|
@@ -44,7 +44,7 @@ temps réel, ce qui n'est pas une vrai contrainte pour nous : je
|
|
44
|
44
|
suspecte qu'un retard en dessous 1 ou 0.5 seconde ne devrait pas nuire
|
|
45
|
45
|
à l'expérience utilisateur.
|
|
46
|
46
|
|
|
47
|
|
-*Côté back-end*, 2 alternatives : garder la connexion vivante avec le
|
|
|
47
|
+**Côté back-end**, 2 alternatives : garder la connexion vivante avec le
|
|
48
|
48
|
client durant tout le traitement ou utiliser 2 types de requêtes : un
|
|
49
|
49
|
premier qui enregistre la demande de traitement et retourne un
|
|
50
|
50
|
identifiant de traitement et un second qui retourne le progrès de ce
|
|
|
@@ -62,7 +62,7 @@ identifiant pour ce travail. La demande d'exécution du traitement ne
|
|
62
|
62
|
retournera donc pas de nouvel identifiant, elle ne fera que changer
|
|
63
|
63
|
l'état du travail.
|
|
64
|
64
|
|
|
65
|
|
-Enfin, *entre le back-end et le process Python*, il me semble
|
|
|
65
|
+Enfin, **entre le back-end et le process Python**, il me semble
|
|
66
|
66
|
raisonnable de garder une connexion pendant toute la durée du
|
|
67
|
67
|
traitement. Un thread du back-end est dédié à lancer le process
|
|
68
|
68
|
Python, à observer le progrès de son exécution et à mettre à jour l'état
|
Gildas Chabot