<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi, Sam<br>
<br>
Thanks for your response. I used 'deliberate' to express my
frustration.<br>
<br>
From the wiki pages, I assume that the collaboration wrapper is
supported in 0.106 although activities that use it must port to
sugar3. The current version of <br>
chat is using this and can act as a tutorial example.<br>
<br>
I have some activities that need this capability so I'll try to give
it a try.<br>
<br>
Thanks<br>
<br>
Tony<br>
<br>
<div class="moz-cite-prefix">On 12/24/2015 09:36 AM, Sam P. wrote:<br>
</div>
<blockquote
cite="mid:CACVKbrU37j-Zf-xPfaq4SXOghNYr8WFAyjaXz4P9AsNV8Q5Jag@mail.gmail.com"
type="cite">
<div dir="ltr">Hi Tony,<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Dec 24, 2015 at 5:35 PM, Tony
Anderson <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:tony_anderson@usa.net" target="_blank">tony_anderson@usa.net</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 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>
</div>
</blockquote>
<div><br>
</div>
<div>Ok, so there is a feature page which gives some
background on all of this: <a moz-do-not-send="true"
href="http://wiki.sugarlabs.org/go/Features/Fixing_Collab_%28Tubes%29">http://wiki.sugarlabs.org/go/Features/Fixing_Collab_(Tubes)</a></div>
<div><br>
</div>
<div>Activities were not deliberately broken, that is quite
strong language to be using about telepathy apis anyway.</div>
<div><br>
</div>
<div>Telepathy has channels, which activities can use to
communicate. There are text channels, file transfer
channels, and even tubes channels. However tubes had an
interesting (read, bad) design that it re-invented the
channel negotiation (requesting a new channel, etc.)
inside a channel! What a crazy design. The telepathy
developers manual also says that it was deprecated because
it lacked extendibility.</div>
<div><br>
</div>
<div>Either way, upstream (telepathy in this case)
deprecated the api. This happened around 7 years ago.
(At least, there are 7 year old or so tickets in BSLO
noting the deprecation). Anyway, for 7 years the api
remained in telepathy and nobody was too bothered. But
recently (whatever telepathy version made it into fedora
22) the api was removed, which breaks sugar and sugar
activities ability to collaborate. This is a very
reasonable deprecation timeframe in my opinion, and
telepathy had all right to remove the api. Importantly,
this is not fedora running amok. </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 text="#000000" bgcolor="#FFFFFF"> <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>
</div>
</blockquote>
<div><br>
</div>
<div>Well, that would be very painful. The 'tubes' api is
not an api provided by sugar, it is provided by telepathy.</div>
<div><br>
</div>
<div>Some of the tubes api concepts (eg. multiple tubes
within 1 channel), don't map very well at all to the
modern telepathy ideas. It would be pretty messy.<br>
</div>
<div><br>
</div>
<div>Every activity that uses tubes also has 160 lines of
code dedicated to negotiating the tubes, all of which are
subtly different in annoying ways (like copy, paste,
change code reuse). It would be a testing nightmare to
get this crazy tubes wrapper to work on all the
activities.</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 text="#000000" bgcolor="#FFFFFF"> <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>
</div>
</blockquote>
<div><br>
</div>
<div>Well, this won't effect XOs unless somebody gets fedora
22+ running on them (most run f18, there is alpha image of
f20 for XO4). As Martin proposed, we can keep the old
behaviour and the old activities will still run, on older
systems.</div>
<div><br>
</div>
<div>While it is annoying to have to port activities to a
new, simple abstraction, in the end it makes it easier for
you to provide new capabilities for XOs. Adding
collaboration will not require copy-and-pray coding with
100s of lines of boilerplate. Instead you can use a
simple, document api: <a moz-do-not-send="true"
href="http://people.sugarlabs.org/sam/docs-collab-wrapper-try2/sugar3.presence.wrapper.html">http://people.sugarlabs.org/sam/docs-collab-wrapper-try2/sugar3.presence.wrapper.html</a></div>
<div><br>
</div>
<div>Thanks,</div>
<div>Sam</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 text="#000000" bgcolor="#FFFFFF"> <br>
Tony
<div>
<div class="h5"><br>
<br>
<br>
<br>
<div>On 12/24/2015 12:34 AM, Sam P. wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div class="h5">
<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"><a class="moz-txt-link-abbreviated" href="mailto:martin.abente.lahaye@gmail.com">martin.abente.lahaye@gmail.com</a></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"
target="_blank">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"
target="_blank">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></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
Sugar-devel mailing list
<a moz-do-not-send="true" href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a>
<a moz-do-not-send="true" href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a>
</pre>
</blockquote>
<br>
</div>
<br>
_______________________________________________<br>
Sugar-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br>
<a moz-do-not-send="true"
href="http://lists.sugarlabs.org/listinfo/sugar-devel"
rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
<br>
</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>