5:47 a.m.
On 7/3/2014 9:39 PM, Aline Manersa wrote:
On 07/03/2014 07:06 AM, Yu Xin Huo wrote:
> For this RFC, we are trying to create a *generic message notification
> component* to handle *long task*.
>
> I do not think any new tab is needed for message subscribe
> configuration.
>
> If this long task is at console admin
> level(host/template/network/storage pool), I recommend to share this
> message among all *root* users.
> If this long task is at VM level, only *VM users* got this message.
>
> The task should be identified by the uri(web api) that triggered it.
+1
About the design, to accomplish that will we use websocket or broker
or ..?
with web socket, below 2 are the unique value.
1. the notification can be initialized from backend.
https://github.com/kimchi-project/kimchi/issues/367 from Christy
2. save client from query task status with a 200ms interval.
if only for long task, web socket is not a must.
Would like to listen to team's voice to have more opinions.
for broker, it is not technological, it is a logical component to
distribute tasks to users and push back to client.
>
> On 6/27/2014 7:15 PM, 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.
>>
>> Best Regards
>>
>> Wang Wen
>>
>>
>>
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>