<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">For this RFC, we are trying to create a
      <b>generic message notification component</b> to handle <b>long
        task</b>.<br>
      <br>
      I do not think any new tab is needed for message subscribe
      configuration.<br>
      <br>
      If this long task is at console admin
      level(host/template/network/storage pool), I recommend to share
      this message among all <b>root</b> users.<br>
      If this long task is at VM level, only <b>VM users</b> got this
      message.<br>
      <br>
      The task should be identified by the uri(web api) that triggered
      it.<br>
      <br>
      On 6/27/2014 7:15 PM, Wen Wang wrote:<br>
    </div>
    <blockquote cite="mid:53AD524B.6020909@linux.vnet.ibm.com"
      type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      Dear all,<br>
      <b><br>
      </b><b>Problems:</b><br>
      Now our strategy&nbsp; 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. <br>
      <br>
      <b>Solution</b>:<br>
      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.<br>
      <br>
      1) Browser needs to register to the back end to indicate which
      part the result needs to reply to when the task finished.<br>
      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.<br>
      3) Using websocket of cherrypy to accomplish the message transfer.<br>
      <br>
      Best Regards<br>
      <br>
      Wang Wen<br>
      <br>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>