<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>El 26/07/16 a las 14:05, Dave Crossland escribió:<br>
    </p>
    <blockquote
cite="mid:CAEozd0yAFxnex2RawkiwSrrAiOw+fFLbX5eZg2S=5qUB1P6p2g@mail.gmail.com"
      type="cite">
      <p dir="ltr"><br>
        On Jul 26, 2016 2:36 PM, "Sebastian Silva" <<a
          moz-do-not-send="true" href="mailto:sebastian@fuentelibre.org"><a class="moz-txt-link-abbreviated" href="mailto:sebastian@fuentelibre.org">sebastian@fuentelibre.org</a></a>>
        wrote:<br>
        ><br>
        > El 26/07/16 a las 13:08, Dave Crossland escribió:<br>
        >><br>
        >> Despite my suggestion to look at zeromq, I think we
        should be using the collaboration protocols that Lionel is using
        in Sugarizer, so that someone running Sugar desktop and someone
        using Sugarizer on a Chromebook (for example, 2 kids in a family
        at home who attend 2 different schools that have different
        hardware purchasing decisions ;) could collaborate.  <br>
        ><br>
        > It's not a dichotomy.<br>
        ><br>
        > If two users use the same app [and it supports
        collaboration] - it should just work regardless of the
        environment where they are run.<br>
        ><br>
        > Much like running etherpad @ titanpad.</p>
      <p dir="ltr">I mean to propose a requirement for any new
        collaboration system that is recommended to all sugar developers
        be that it support collaboration between a python paint
        application and a Javascript paint application. </p>
    </blockquote>
    That sounds challenging and not too useful.<br>
    <blockquote
cite="mid:CAEozd0yAFxnex2RawkiwSrrAiOw+fFLbX5eZg2S=5qUB1P6p2g@mail.gmail.com"
      type="cite">
      <p dir="ltr">And therefore the system that meets that requirement
        is the one used by sugarizer today. <br>
      </p>
      <p dir="ltr">>> However, I am eagerly awaiting Sameer's next
        installment of the vision quest process, because without the
        vision/mission/etc defined, we can't make informed technical
        decisions about what kind of collaboration protocols are best.<br>
        ><br>
        ><br>
        > Maybe we shouldn't have to judge - they can all coexist.</p>
      <p dir="ltr">An anti-design approach where no system is
        recommended and each activity developer can figure out their own
        system seems counter to the aims of a cohesive and consistent
        learning platform in which collaboration is promoted as a top
        tier feature :)</p>
    </blockquote>
    User facing features are at the application level. How they are
    implemented is only a detail. I'd rather have a paint app that
    collaborates, no matter how it is built. Currently we have none.<br>
    <br>
    It is part of our philosophy to promote collaboration - at all
    levels - open organizations, user freedom, git, wiki, etc.<br>
  </body>
</html>