[Sugar-devel] Current status of collaboration work
tony_anderson at usa.net
Thu Dec 24 06:48:20 EST 2015
Thanks for your response. I used 'deliberate' to express my frustration.
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
chat is using this and can act as a tutorial example.
I have some activities that need this capability so I'll try to give it
On 12/24/2015 09:36 AM, Sam P. wrote:
> Hi Tony,
> On Thu, Dec 24, 2015 at 5:35 PM, Tony Anderson <tony_anderson at usa.net
> <mailto:tony_anderson at usa.net>> wrote:
> 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?
> Ok, so there is a feature page which gives some background on all of
> this: http://wiki.sugarlabs.org/go/Features/Fixing_Collab_(Tubes)
> Activities were not deliberately broken, that is quite strong language
> to be using about telepathy apis anyway.
> 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.
> 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.
> 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
> applications do not have to be modified. This, after all, was the
> purpose of 'object programming'.
> Well, that would be very painful. The 'tubes' api is not an api
> provided by sugar, it is provided by telepathy.
> 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.
> 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.
> 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
> 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.
> 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:
> On 12/24/2015 12:34 AM, Sam P. wrote:
>> Hi Martin,
>> On Thu, Dec 24, 2015 at 6:52 AM, Martin Abente
>> <martin.abente.lahaye at gmail.com
>> <mailto:martin.abente.lahaye at gmail.com>> wrote:
>> Hello everyone,
>> 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.
>> 1. There haven't been enough changes in the Activities
>> regarding Tubes deprecation.
>> 2. 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.
>> 3. Making changes in the Sugar API without proper testing
>> with more activities (and scenarios) is simply not a good
>> 4. But, making changes in the Activities can be easily
>> handled since they are self contained.
>> 5. Most of our users still use Fedora 18 through OLPC
>> deployments, where Tubes is available.
>> 1. Lets make Sugar handle the Tubes deprecation better so it
>> doesn't break, but lets not remove the support for TUBES yet.
>> 2. Instead, we can start changing the activities using the
>> Wrapper that Walter and Sam prepared, but using it
>> locally on each Activity for now.
>> 3. 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.
>> 1. We avoid breaking collaboration for *(a)* Activities that
>> use TUBES and run on older systems where TUBES is
>> available, and *(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.
>> 2. We do this whole re-work incrementally, without having to
>> change the API (sort of) blindly.
>> 3. There will be more flexibility to explore ideas in
>> Activities land.
>> 1. There will be repeated code in Activities, but that can
>> be changed easily later.
>> *What would be needed:*
>> 1. To detect if there is TUBES support, as Sam mentioned in
>> his first PR . *Can someone look into this?*
>> 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?
>> 2. Do not create TUBES channel when there is not support.
>> This  is just a hack and the logic works fine, but it
>> depends on whether or not we can detect support.
>> 1. Cleanup the Wrapper and make sure that it is possible to
>> use it locally in activities.
>> Yep, the wrapper can already be used locally in activities, see
>> Bibliography activity  and physics activity .
>> 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.
>> *Other improvements that we could land now:*
>> 1. Give more flexibility to activities to use file transfer
>> channels without having the shell messing with them. 
>> 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.
>> Good write up by the way.
>>  https://github.com/walterbender/physics/pull/10
>> If we don't do something about this, next Sugar releases will
>> still be broken for collaboration, for more scenarios than
>> Let me know what you guys think,
>>  https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/270
>>  https://github.com/sugarlabs/sugar/pull/621
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> <mailto:Sugar-devel at lists.sugarlabs.org>
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> <mailto:Sugar-devel at lists.sugarlabs.org>
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Sugar-devel