<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Sam,<br>
    <br>
    I am still not clear on the status. I have a long-dormant activity
    'bingo' which depends on the caller sending 'bingo cards', receiving
    a 'bingo call', and being able to check the card via collaboration.
    In developing those features, should I use the collab wrapper? Is it
    available for 0.106? Where can I find the version of <br>
    chat that uses it as an example to follow? The version installed on
    0.106 (13.2.5) does not seem to use it.<br>
    <br>
    Tony<br>
    <br>
    <div class="moz-cite-prefix">On 12/26/2015 01:55 AM, Gonzalo Odiard
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAJ+iPVT8=Ejxc8RCoX5S_MjaLnnA1AMcvR2VFZnzffLfdt_HLw@mail.gmail.com"
      type="cite">
      <div dir="ltr">Hi Martin,
        <div>I like your proposal of use the wrapper in the activities
          by at least one cycle, before include it in the toolkit.</div>
        <div>In our experience, once the code is included in the
          toolkit, is difficult make changes without breaking activities
          in</div>
        <div>unexpected ways.</div>
        <div>I didn't have time to make tests with the wrapper, and is
          really difficult do tests for collaboration. We have seen</div>
        <div>bugs that appear only when you have many computers, or
          using jabber but not when using the mesh, etc.</div>
        <div>I think the wrapper is a very, very good start (Thanks Sam
          and Walter) and even they provided patches for some
          activities.</div>
        <div>Sadly, some of the activities are on my hands, but I didn't
          have time the last months to do the proper testing</div>
        <div>and integration of the patches.</div>
        <div>About the wrapper API, just looking at the code, I think
          would be better add a callback parameter to the setup() method</div>
        <div>because the initialization is async and then is the only
          way to execute your activity code when the initialization</div>
        <div>has finished. Issues like this are difficult to get right
          at the first time.</div>
        <div>I know I am not doing almost any work in sugar these
          months, don't take these comments as a critic,</div>
        <div>just as a way to try to help, and avoid problems in the
          future.</div>
        <div>Regards,</div>
        <div><br>
        </div>
        <div>Gonzalo</div>
        <div>   </div>
        <div><br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Wed, Dec 23, 2015 at 4:52 PM, Martin
          Abente <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:martin.abente.lahaye@gmail.com"
              target="_blank">martin.abente.lahaye@gmail.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div dir="ltr">
              <div>Hello everyone,</div>
              <div><br>
              </div>
              <div>I have been reviewing the current state of the
                collaboration proposals and I am afraid it is still too
                early for merging it. We need to explore more use cases,
                and this will only happens when we start porting more
                Activities that actually use TUBES. Therefore, i want to
                share some thoughts on this.</div>
              <div><br>
              </div>
              <div><b>Opinions:</b></div>
              <div>
                <ol>
                  <li>There haven't been enough changes in the
                    Activities regarding Tubes deprecation.<br>
                  </li>
                  <li>Dropping the Tubes support from Sugar without
                    changing all the activities that depend on Tubes
                    means that we will break collaboration for those
                    activities anyway, and there wont be much gain by
                    just doing that.<br>
                  </li>
                  <li>Making changes in the Sugar API without proper
                    testing with more activities (and scenarios) is
                    simply not a good idea.<br>
                  </li>
                  <li>But, making changes in the Activities can be
                    easily handled since they are self contained.<br>
                  </li>
                  <li>Most of our users still use Fedora 18 through OLPC
                    deployments, where Tubes is available.</li>
                </ol>
              </div>
              <div><b>Suggestions:</b></div>
              <div>
                <ol>
                  <li>Lets make Sugar handle the Tubes deprecation
                    better so it doesn't break, but lets not remove the
                    support for TUBES yet.<br>
                  </li>
                  <li>Instead, we can start changing the activities
                    using the Wrapper that Walter and Sam prepared, but
                    using it locally on each Activity for now.<br>
                  </li>
                  <li>Once and if, we have most of our activities ported
                    to the new telepathy API (which will be based on the
                    Wrapper), then we can include the Wrapper into
                    sugar-toolkit-gtk3, in a next release and remove it
                    from Activities.</li>
                </ol>
              </div>
              <div><b>Pros:</b></div>
              <div>
                <ol>
                  <li>We avoid breaking collaboration for <b>(a)</b>
                    Activities that use TUBES and run on older systems
                    where TUBES is available, and <b>(b)</b> Activities
                    that does not use TUBES on newer systems where TUBES
                    is no longer available. This _is_ an improvement
                    versus the current situation where is completely
                    broken on newer systems.</li>
                  <li>We do this whole re-work incrementally, without
                    having to change the API (sort of) blindly.<br>
                  </li>
                  <li>There will be more flexibility to explore ideas in
                    Activities land.</li>
                </ol>
              </div>
              <div><b>Cons:</b></div>
              <div>
                <ol>
                  <li>There will be repeated code in Activities, but
                    that can be changed easily later.<br>
                  </li>
                </ol>
              </div>
              <div><br>
              </div>
              <div><b>What would be needed:</b></div>
              <div>
                <ol>
                  <li>To detect if there is TUBES support, as Sam
                    mentioned in his first PR [1]. <b>Can someone look
                      into this?</b><br>
                  </li>
                  <li>Do not create TUBES channel when there is not
                    support. This [2] is just a hack and the logic works
                    fine, but it depends on whether or not we can detect
                    support.</li>
                  <li>Cleanup the Wrapper and make sure that it is
                    possible to use it locally in activities.</li>
                </ol>
              </div>
              <div><b>Other improvements that we could land now:</b></div>
              <div>
                <ol>
                  <li>Give more flexibility to activities to use file
                    transfer channels without having the shell messing
                    with them. [3]</li>
                </ol>
              </div>
              <div><b>Conclusions:</b></div>
              <div><br>
              </div>
              <div>If we don't do something about this, next Sugar
                releases will still be broken for collaboration, for
                more scenarios than necessary.</div>
              <div><br>
              </div>
              <div><br>
              </div>
              <div>Let me know what you guys think,<br>
              </div>
              <div>Martin.</div>
              <div><br>
              </div>
              <div><b>Refs:</b></div>
              <div>[1] <a moz-do-not-send="true"
                  href="https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/270"
                  target="_blank">https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/270</a></div>
              <div>[2] <a moz-do-not-send="true"
href="https://github.com/tchx84/sugar-toolkit-gtk3/commit/bed0ac5f4259ff1669323db26acb27f5d9c8ed1f"
                  target="_blank">https://github.com/tchx84/sugar-toolkit-gtk3/commit/bed0ac5f4259ff1669323db26acb27f5d9c8ed1f</a></div>
              <div>[3] <a moz-do-not-send="true"
                  href="https://github.com/sugarlabs/sugar/pull/621"
                  target="_blank">https://github.com/sugarlabs/sugar/pull/621</a></div>
            </div>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <div><br>
        </div>
        -- <br>
        <div class="gmail_signature">
          <div dir="ltr">
            <div>
              <div dir="ltr">Gonzalo Odiard<br>
                <br>
                <div>SugarLabs - Software [for | by] children learning <br>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Sugar-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>