On 06/27/2014 08:15 AM, Wen Wang wrote:
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.
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.
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?
Kimchi-devel mailing list