<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi,<br>
<br>
It would really be helpful for us to get an explanation when working
activities are deliberately broken ('deprecated') as in this case.
What is the new means to implement collaboration? What advantage
does it offer to the 'tubes' method we have been using from the
beginning? Is this another example of Fedora run amok? <br>
<br>
As you say, the traditional way to handle this particular case would
be to re-write the 'tubes' api using whatever the new method is so
that the existing <br>
applications do not have to be modified. This, after all, was the
purpose of 'object programming'.<br>
<br>
It is really frustrating when one is trying to provide new
capabilities for the XO to have to spend almost all of the time
re-implementing activities that have stopped working in the newer
releases.<br>
<br>
Tony<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 12/24/2015 12:34 AM, Sam P. wrote:<br>
</div>
<blockquote
cite="mid:CACVKbrXh4LqJ1V6rKGc8BpcryZy87iuXwSVfMXRic-4M-WUa+Q@mail.gmail.com"
type="cite">
<div dir="ltr">Hi Martin,<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Dec 24, 2015 at 6:52 AM,
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:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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></li>
</ol>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I looked into this a while ago, and it didn't seem that
it would be easy. Maybe we could add a gsetting that
defaults to off (for new distros) and then OLPC OS Builder
can turn it on to say give activities tubes? </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div>
<ol>
<li><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>
</ol>
</div>
</div>
</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div>
<ol>
<li>Cleanup the Wrapper and make sure that it is
possible to use it locally in activities.</li>
</ol>
</div>
</div>
</blockquote>
<div>Yep, the wrapper can already be used locally in
activities, see Bibliography activity [1] and physics
activity [2].</div>
<div><br>
</div>
<div>However, I do believe that the fact that activities are
using a wrapper doesn't stop up from also having it in
sugar3. As you noted, it is repeated code in activities.
It is easier to change the sugar3 code later as needed
than to change the wrapper code in every activity.
Therefore, I believe that we should have a try/except
clause to preference the sugar3 wrapper, but fallback to
the local one.</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<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>
</blockquote>
<div>As a note, the wrapper makes heavy use of file
transfers (eg. for init) currently. This does result in
shell notifications on older Sugars, although the
activities can still collaborate.</div>
<div><br>
</div>
<div>Good write up by the way.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Sam</div>
<div><br>
</div>
<div>[1] <a moz-do-not-send="true"
href="https://github.com/samdroid-apps/bibliography-activity/tree/collab">https://github.com/samdroid-apps/bibliography-activity/tree/collab</a></div>
<div>[2] <a moz-do-not-send="true"
href="https://github.com/walterbender/physics/pull/10">https://github.com/walterbender/physics/pull/10</a> <br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<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>
</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>