<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Daniel,<br>
    <br>
    <div class="moz-cite-prefix">On 02/08/2017 05:07 PM, Daniel Henrique
      Barboza wrote:<br>
    </div>
    <blockquote
      cite="mid:2bf265f6-8c40-4517-0776-191d8dcdc2d3@gmail.com"
      type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=windows-1252">
      Hi everyone,<br>
      <br>
      I want to start a discussion on <a moz-do-not-send="true"
        class="moz-txt-link-freetext"
        href="https://github.com/kimchi-project/wok/issues/16">https://github.com/kimchi-project/wok/issues/16</a>,<br>
      "<span class="js-issue-title" style="box-sizing: border-box;">Asynchronous
        event notification".<br>
        <br>
        As most of you are aware, WoK does not have any sort of push
        notification. WoK<br>
        UI works based on a polling strategy using the Notifications API
        to fetch for any<br>
        backend notifications. This polling is on a 3 second interval to
        not overload the server<br>
        with these requests. The problems with this approach are
        obvious: the cost of<br>
        the polling process for both UI and backend, the interval for a
        backend event to be<br>
        delivered to the UI and so forth.<br>
        <br>
        - The idea<br>
        <br>
        This work aims to implement an asynchronous strategy to deliver
        server to client<br>
        messages. The idea is to use websockets* to establish a socket
        connection between<br>
        the UI and the backend. The backend can send any message using
        this socket and<br>
        the UI, after receiving it, can act upon immediately.<br>
        <br>
        <br>
        - Push server implementation<br>
        <br>
        This socket in the backend side would act as a 'push server'
        that will receive the<br>
        connections and push the same messages to all of them. Only
        server to client<br>
        messages will be sent. <br>
        <br>
        This push server can be implemented in two ways:<br>
        <br>
        * from scratch<br>
        <br>
        * using an external library<br>
        <br>
        One library that seems to do this asynchronous socket
        implementation is tornado<br>
        ( <a moz-do-not-send="true" class="moz-txt-link-freetext"
          href="https://github.com/tornadoweb/tornado">https://github.com/tornadoweb/tornado</a>
        ). It is present in all distros we support<br>
        and it has Apache 2.0 licensing. I'll experiment with it and see
        if it helps. I am<br>
        opened to any other suggestion of libraries that can be used in
        the push server<br>
        implementation. If no library is good enough for us, I'll have
        to implement it from<br>
        scratch.<br>
        <br>
      </span></blockquote>
    <br>
    I am OK in using it as it is available for Fedora 25, Ubuntu 16.10,
    openSUSE 42.2 and centOS 7.<br>
    <br>
    It would be good to confirm it is also available for Debian 8 as
    Lucio is working to get the package into the official distro.<br>
    <br>
    <blockquote
      cite="mid:2bf265f6-8c40-4517-0776-191d8dcdc2d3@gmail.com"
      type="cite"><span class="js-issue-title" style="box-sizing:
        border-box;"> <br>
        - WoK backend design<br>
        <br>
        In WoK backend, my idea is to reuse the 'add_notification'
        method from the<br>
        existing Notifications API. When adding a notification, fire a
        message to the<br>
        push server and notify all the listeners too.<br>
        <br>
      </span></blockquote>
    <br>
    Could you elaborate more on that?<br>
    For example, in Kimchi, after adding/starting/deleting a VM we will
    need to notify all the browsers sessions to update the data in UI.<br>
    Or on Wok, after enabling/disabling a plugin.<br>
    <br>
    How will that be done with the notifications API?<br>
    <br>
    From the documentation, the notifications API is as below:<br>
    <br>
    * **GET**: Retrieve the full description of the
    Notification                    <br>
        * code: message
    ID                                                          <br>
        * message: message text already
    translated                                  <br>
        * timestamp: first time notification was emitted    <br>
    <br>
    <blockquote
      cite="mid:2bf265f6-8c40-4517-0776-191d8dcdc2d3@gmail.com"
      type="cite"><span class="js-issue-title" style="box-sizing:
        border-box;"> This approach has the following advantages:<br>
        <br>
        - it will work out of the box for all backend messages in all
        plug-ins that<br>
        uses the 'add_notification' method;<br>
        <br>
      </span></blockquote>
    <br>
    Today, the notifications API is only shown on UI as a warning
    message to the user.<br>
    So I think much UI changes will be required.<br>
    <br>
    <blockquote
      cite="mid:2bf265f6-8c40-4517-0776-191d8dcdc2d3@gmail.com"
      type="cite"><span class="js-issue-title" style="box-sizing:
        border-box;"> - we can re-use the same JSON message format of
        the Notifications API,<br>
        reducing the amount of UI work we'll have to adapt the existing
        UIs;<br>
        <br>
      </span></blockquote>
    <br>
    Same I commented above.<br>
    <br>
    <blockquote
      cite="mid:2bf265f6-8c40-4517-0776-191d8dcdc2d3@gmail.com"
      type="cite"><span class="js-issue-title" style="box-sizing:
        border-box;"> - it will be harmless to implement. Given that the
        push server will send<br>
        messages to all connected UI endpoints, if no endpoint is
        connect<br>
        no message will be sent.<br>
        <br>
        <br>
        - WoK frontend design<br>
        <br>
        For any tab that wants to receive the push notifications, just
        connect<br>
        to the push server via websocket and react to the messages sent
        - just<br>
        like it is done today with the notifications API but without the
        need of<br>
        sending the GET /notifications messages.<br>
        <br>
        We will need to be careful to not open unnecessary websockets
        when<br>
        tab switching. We will need to pay attention to closing up the
        connections<br>
        we don't need anymore.<br>
        <br>
      </span></blockquote>
    <br>
    Why do not open just one on Wok and reuse for all the plugins?<br>
    <br>
    <blockquote
      cite="mid:2bf265f6-8c40-4517-0776-191d8dcdc2d3@gmail.com"
      type="cite"><span class="js-issue-title" style="box-sizing:
        border-box;"> I am planning to do a proof of concept of an UI
        working with this new<br>
        push server notifications in the 'User Log' tab, together with
        this backend<br>
        work. When a new log entry is created, a push notification is
        sent and the<br>
        UI would refresh automatically. This implementation would be
        used as a base<br>
        for the other tabs/plug-ins.<br>
        <br>
        <br>
        Let me know what you think!<br>
        <br>
        <br>
        Daniel<br>
        <br>
        <br>
        PS: for the record, before deciding to use websockets I've
        considered using SSE<br>
        (Server-side Events), a HTML5 standard, but gave up due to lack
        of SSE support<br>
        from Microsoft browsers.<br>
      </span> <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>