On 7/2/2014 10:04 AM, Aline Manera
wrote:
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.