<div dir="ltr">Hi James,<br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 26, 2015 at 2:28 PM, James Cameron <span dir="ltr"><<a href="mailto:quozl@laptop.org" target="_blank">quozl@laptop.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks all for the thread and replies.<br>
<br>
I'm not sure I understand the situation fully yet, but I'll make some<br>
comments regardless. Hopefully any disconnect between my comments and<br>
your understanding will help fix mine.<br>
<br>
I've learned long ago, to not change network protocols in a way that<br>
breaks things. Interoperability is critical, regardless of difficulty<br>
of implementation or complexity.<br>
<br>
The Tubes API is effectively a network protocol.<br>
<br>
If we release a version of Sugar that is incompatible with previous<br>
versions of Sugar, at a network protocol level, what will happen?<br></blockquote><div><br></div><div>The tubes API is kind of a network protocol. We also can't drop tubes from sugar per se, activities consume raw tubes. On telepathy versions that tubes are not avaliable, we never give any channels to the activity because we wait (forever) for a tube. If the activity requires a tube, but sugar does not give it one, it will also break in unexpected ways.</div><div><br></div><div>In effect, if the user is using a "new" (not using tubes) activity things will work on any system where it gives the text channel to the activity. This included old sugar 98 systems, OLPC OS 13/14 systems and patched fedora 24 systems.</div><div><br></div><div>If these users are updating their activities, everything will be fine. Moving away from tubes will mean that the "old" (tubes) version of the activity can not collaberate with the "new" (non tubes) version of the activity. However, if both users update their activities, all is well.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If we release a version of an activity with incompatibility, what<br>
will happen?<br>
<br>
We've seen what happens, even with the trivial problems introduced by<br>
the <a href="http://activity.info" rel="noreferrer" target="_blank">activity.info</a> file and the Gtk3 port. The bias of the first<br>
failure report is severe and lasting. Our users don't upgrade. They<br>
persist with an old version of Sugar, like 0.96 on OLPC OS 12.1.0. In<br>
effect, they ignore the Sugar developer community until the job is<br>
finished, the problems are fixed, or sufficient reasons are built up<br>
to upgrade. During which we have no end-user feedback into the<br>
development process. It has taken years to recover from the post-0.96<br>
breakage.<br>
<br>
Tony made a remark about Fedora amok. Perhaps it was deeper than<br>
that, perhaps it was a failure of advocacy for the Tubes API, in the<br>
context of the Telepathy community, by members of the Sugar Labs<br>
developer community. Rhetorical; did they know we were using it?<br>
<br>
If it was a failure of advocacy, we must expect further instances.<br>
Some other API will disappear.<br></blockquote><div><br></div><div>*Looks at WebKit2*</div><div><br></div><div>I should probably comment more on that webkit ticket.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I've seen no detailed analysis of adopting the Tubes API into Sugar.<br>
Why not? What is so hard about taking the latest version of Tubes API<br>
and integrating it into the Sugar code base in a way that we can<br>
continue to use it?<br></blockquote><div><br></div><div>There is no new tubes api. And porting to a DBusTube channel or StreamTube channel is probably as hard as porting to CollabWrapper - most of the activity collab code is spend on tube initiation. It believe that it is obviously advantageous to move the collaboration setup code into a shared wrapper, rather than migrate it from tube initiation to DBusTube negotiation.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Pull request 282 mentions 0.17.25, but of what package? When did the<br>
Tubes API get removed from the Telepathy packages? Yes, for Fedora it<br>
was 22, but we care about other downstreams.<br></blockquote><div><br></div><div>I reference the telepathy spec version. However, I do not know and can not find where these map into telepathy-{gabbel,salut} versions.</div><div><br></div><div>You also touch on gabble vs salut later on and mention that salut still supports tubes. Maybe salut should be our new default then given it supports older activities? (also, <a href="http://jabber.sugarlabs.org">jabber.sugarlabs.org</a> is way to busy to find any buddies!)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Fedora 18 builds with Sugar 0.107.0, I'm using<br>
<br>
telepathy-mission-control 5.14.0<br>
telepathy-salut 0.8.1<br>
telepathy-gabble 0.16.7<br>
python-telepathy 0.15.19<br>
telepathy-glib 0.20.4<br>
<br>
On Fedora 20 builds, I'm using<br>
<br>
telepathy-mission-control 5.16.3<br>
telepathy-salut 0.8.1<br>
telepathy-gabble 0.18.2<br>
python-telepathy 0.15.19<br>
telepathy-glib 0.22.0<br>
<br>
On Ubuntu 14.04 builds with Sugar 0.107.0, I'm using<br>
<br>
telepathy-mission-control 5.16.1<br>
telepathy-salut 0.8.1<br>
telepathy-gabble-legacy 0.16.7<br>
python-telepathy 0.15.19<br>
libtelepathy-glib0 0.22.1<br>
<br>
On Ubuntu 15.10 builds with Sugar 0.107.0, I'm using<br>
<br>
telepathy-mission-control 5.16.3<br>
telepathy-salut 0.8.1<br>
telepathy-gabble-legacy 0.16.7<br>
python-telepathy 0.15.19<br>
libtelepathy-glib0 0.24.1<br>
<br>
On Fedora 24 <a href="http://koji.fedoraproject.org" rel="noreferrer" target="_blank">koji.fedoraproject.org</a> says we'll expect<br>
<br>
telepathy-mission-control 5.16.3<br>
telepathy-salut 0.8.1<br>
telepathy-gabble 0.18.2<br>
python-telepathy 0.15.19<br>
telepathy-glib 0.24.1<br>
<br>
I don't have a test case for collaboration failure due to Tubes API<br>
missing. The feature page doesn't say. I can't find a bug report.<br></blockquote><div><br></div><div>Test case: Try joining any (any!) activity on a device that does not have tubes. Your activity will not get a tubes channel (activities may call this a connection in front of the user).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The constant CHANNEL_TYPE_TUBES is to be removed?<br>
<br>
I've seen patches that remove it from<br>
<br>
sugar-toolkit-gtk3:src/sugar3/presence/activity.py<br>
<br>
But none that remove it from<br>
<br>
sugar-toolkit:src/sugar/presence/activity.py<br>
<br>
Which is still used by older activities, right?<br>
<br>
On the activity set bundled with OLPC OS 13.2.6, references to<br>
CHANNEL_TYPE_TUBES can be found in activities; Record, Browse, Read,<br>
ImageViewer, Pippy, StopWatch, TurtleBlocks, TurtleBlocks, Distance,<br>
Calculate, Physics, Memorize, and Write.<br>
<br>
The feature page doesn't list these or other activities to be<br>
changed. Do we know, or are we just hoping to remember them all?<br></blockquote><div><br></div><div>Yes, that was the idea :)</div><div><br></div><div>I will add a list to the page in the near future, however you are welcome to do so if you beat me to it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'm also wanting to see an interoperability matrix of some sort; will<br>
new activities work on old Sugar, will old activities work on new<br>
Sugar, etc. I'll need to take that into account for users upgrading<br>
laptops, where either Sugar or activities may be upgraded independently.<br></blockquote><div><br></div><div>In words: activity version updates will need to be coordinated between buddies (who wish to collaborate). If the collaberation does not work on the current version of sugar, they will need to update sugar. However, buddies on different sugar versions and the same activity versions will be able to collaborate.</div><div><br></div><div>My attempt at a table:</div><div><br></div><div>----------------| new activity | old activity |</div><div>New Sugar | YES | if tubes supported on device |</div><div>----------------|-----------------|----------------|</div><div>Old Sugar | YES | if tubes supported on device |</div><div><br></div><div>Thanks,</div><div>Sam</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It would seem that the Tubes API was fairly critical to Sugar's<br>
success. ;-)<br>
<div><div class="h5"><br>
On Fri, Dec 25, 2015 at 08:55:18PM -0300, Gonzalo Odiard wrote:<br>
> Hi Martin,<br>
> I like your proposal of use the wrapper in the activities by at least one<br>
> cycle, before include it in the toolkit.<br>
> In our experience, once the code is included in the toolkit, is difficult make<br>
> changes without breaking activities in<br>
> unexpected ways.<br>
> I didn't have time to make tests with the wrapper, and is really difficult do<br>
> tests for collaboration. We have seen<br>
> bugs that appear only when you have many computers, or using jabber but not<br>
> when using the mesh, etc.<br>
> I think the wrapper is a very, very good start (Thanks Sam and Walter) and even<br>
> they provided patches for some activities.<br>
> Sadly, some of the activities are on my hands, but I didn't have time the last<br>
> months to do the proper testing<br>
> and integration of the patches.<br>
> About the wrapper API, just looking at the code, I think would be better add a<br>
> callback parameter to the setup() method<br>
> because the initialization is async and then is the only way to execute your<br>
> activity code when the initialization<br>
> has finished. Issues like this are difficult to get right at the first time.<br>
> I know I am not doing almost any work in sugar these months, don't take these<br>
> comments as a critic,<br>
> just as a way to try to help, and avoid problems in the future.<br>
> Regards,<br>
><br>
> Gonzalo<br>
> <br>
><br>
</div></div>> On Wed, Dec 23, 2015 at 4:52 PM, Martin Abente <[1]<br>
<span class="">> <a href="mailto:martin.abente.lahaye@gmail.com">martin.abente.lahaye@gmail.com</a>> wrote:<br>
><br>
> Hello everyone,<br>
><br>
> I have been reviewing the current state of the collaboration proposals and<br>
> I am afraid it is still too early for merging it. We need to explore more<br>
> use cases, and this will only happens when we start porting more Activities<br>
> that actually use TUBES. Therefore, i want to share some thoughts on this.<br>
><br>
> Opinions:<br>
</span>> 1. There haven't been enough changes in the Activities regarding Tubes<br>
> deprecation.<br>
> 2. Dropping the Tubes support from Sugar without changing all the<br>
<span class="">> activities that depend on Tubes means that we will break collaboration<br>
> for those activities anyway, and there wont be much gain by just doing<br>
> that.<br>
</span>> 3. Making changes in the Sugar API without proper testing with more<br>
<span class="">> activities (and scenarios) is simply not a good idea.<br>
</span>> 4. But, making changes in the Activities can be easily handled since they<br>
> are self contained.<br>
> 5. Most of our users still use Fedora 18 through OLPC deployments, where<br>
> Tubes is available.<br>
> Suggestions:<br>
> 1. Lets make Sugar handle the Tubes deprecation better so it doesn't<br>
<span class="">> break, but lets not remove the support for TUBES yet.<br>
</span>> 2. Instead, we can start changing the activities using the Wrapper that<br>
<span class="">> Walter and Sam prepared, but using it locally on each Activity for now.<br>
</span>> 3. Once and if, we have most of our activities ported to the new telepathy<br>
<span class="">> API (which will be based on the Wrapper), then we can include the<br>
> Wrapper into sugar-toolkit-gtk3, in a next release and remove it from<br>
> Activities.<br>
> Pros:<br>
</span>> 1. We avoid breaking collaboration for (a) Activities that use TUBES and<br>
<span class="">> run on older systems where TUBES is available, and (b) Activities that<br>
> does not use TUBES on newer systems where TUBES is no longer available.<br>
> This _is_ an improvement versus the current situation where is<br>
> completely broken on newer systems.<br>
</span>> 2. We do this whole re-work incrementally, without having to change the<br>
> API (sort of) blindly.<br>
> 3. There will be more flexibility to explore ideas in Activities land.<br>
> Cons:<br>
> 1. There will be repeated code in Activities, but that can be changed<br>
<span class="">> easily later.<br>
><br>
> What would be needed:<br>
</span>> 1. To detect if there is TUBES support, as Sam mentioned in his first PR<br>
<span class="">> [1]. Can someone look into this?<br>
</span>> 2. Do not create TUBES channel when there is not support. This [2] is just<br>
<span class="">> a hack and the logic works fine, but it depends on whether or not we<br>
> can detect support.<br>
</span>> 3. Cleanup the Wrapper and make sure that it is possible to use it locally<br>
<span class="">> in activities.<br>
> Other improvements that we could land now:<br>
</span>> 1. Give more flexibility to activities to use file transfer channels<br>
<span class="">> without having the shell messing with them. [3]<br>
> Conclusions:<br>
><br>
> If we don't do something about this, next Sugar releases will still be<br>
> broken for collaboration, for more scenarios than necessary.<br>
><br>
> Let me know what you guys think,<br>
> Martin.<br>
><br>
> Refs:<br>
</span>> [1] [2]<a href="https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/270" rel="noreferrer" target="_blank">https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/270</a><br>
> [2] [3]<a href="https://github.com/tchx84/sugar-toolkit-gtk3/commit/" rel="noreferrer" target="_blank">https://github.com/tchx84/sugar-toolkit-gtk3/commit/</a><br>
> bed0ac5f4259ff1669323db26acb27f5d9c8ed1f<br>
> [3] [4]<a href="https://github.com/sugarlabs/sugar/pull/621" rel="noreferrer" target="_blank">https://github.com/sugarlabs/sugar/pull/621</a><br>
<span class="">><br>
> --<br>
> Gonzalo Odiard<br>
><br>
> SugarLabs - Software [for | by] children learning <br>
><br>
</span>> References:<br>
><br>
> [1] mailto:<a href="mailto:martin.abente.lahaye@gmail.com">martin.abente.lahaye@gmail.com</a><br>
> [2] <a href="https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/270" rel="noreferrer" target="_blank">https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/270</a><br>
> [3] <a href="https://github.com/tchx84/sugar-toolkit-gtk3/commit/bed0ac5f4259ff1669323db26acb27f5d9c8ed1f" rel="noreferrer" target="_blank">https://github.com/tchx84/sugar-toolkit-gtk3/commit/bed0ac5f4259ff1669323db26acb27f5d9c8ed1f</a><br>
> [4] <a href="https://github.com/sugarlabs/sugar/pull/621" rel="noreferrer" target="_blank">https://github.com/sugarlabs/sugar/pull/621</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
James Cameron<br>
<a href="http://quozl.netrek.org/" rel="noreferrer" target="_blank">http://quozl.netrek.org/</a><br>
</font></span></blockquote></div><br></div></div>