On 06/27/2014 08:15 AM, Wen Wang
wrote:
Dear all,
Problems:
Now our strategy for long time operation is using task which
the browser needs to check up-to-date task status time by time
until the task ends. It's time consuming and less efficient.
Also there exists several problems when locating each task when
doing debug generating and storage pool as well as some new
features that might use task strategy in the future.
Solution:
As talked with Sheldon and Zhengsheng, we came up with a
solution that avoid browser checking status every 200ms. Also,
we might need some more labels in each task to provide more
information when getting the task like we might need to indicate
which operation triggered certain task. What's in our mind is to
use the strategy that allow the server inform browser about the
task information. Our proposal is designed as follows.
1) Browser needs to register to the back end to indicate which
part the result needs to reply to when the task finished.
2) The back end use broker to manage message distribution: when
a task is finished or experiencing an error, back end inform the
browser certain part of work is finished or error.
3) Using websocket of cherrypy to accomplish the message
transfer.
+1
We just need more details to accomplish that
Can we do it in 3 weeks (1 sprint)? or 1 sprint for backend and
other one for the frontend?
We discussed today.It depends on how much we want to use this new
feature. Though it's a good feature, we might need to redesign all
task in the back-end and might need a new tab in the front which
indicates user what kind of message they want to register. Also just
for the task issue, simply we might just need to add some pairs of
keys that provide more information of the task so that the browser
will identify which user is running which tasks, in which case, we
still need the browser check over and over again whether one task is
finished.