[Sugar-devel] Current status of collaboration work

Tony Anderson tony_anderson at usa.net
Thu Dec 24 06:48:20 EST 2015

Hi, Sam

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 
a try.



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:
>     Hi,
>     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) 
> <http://wiki.sugarlabs.org/go/Features/Fixing_Collab_%28Tubes%29>
> 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
>     releases.
> 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: 
> http://people.sugarlabs.org/sam/docs-collab-wrapper-try2/sugar3.presence.wrapper.html
> Thanks,
> Sam
>     Tony
>     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.
>>         *Opinions:*
>>          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
>>             idea.
>>          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.
>>         *Suggestions:*
>>          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.
>>         *Pros:*
>>          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.
>>         *Cons:*
>>          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 [1]. *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?
>>         1.
>>          2. 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.
>>          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 [1] and physics activity [2].
>>     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. [3]
>>     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.
>>     Thanks,
>>     Sam
>>     [1]
>>     https://github.com/samdroid-apps/bibliography-activity/tree/collab
>>     [2] https://github.com/walterbender/physics/pull/10
>>         *Conclusions:*
>>         If we don't do something about this, next Sugar releases will
>>         still be broken for collaboration, for more scenarios than
>>         necessary.
>>         Let me know what you guys think,
>>         Martin.
>>         *Refs:*
>>         [1] https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/270
>>         [2]
>>         https://github.com/tchx84/sugar-toolkit-gtk3/commit/bed0ac5f4259ff1669323db26acb27f5d9c8ed1f
>>         [3] https://github.com/sugarlabs/sugar/pull/621
>>     _______________________________________________
>>     Sugar-devel mailing list
>>     Sugar-devel at lists.sugarlabs.org
>>     <mailto:Sugar-devel at lists.sugarlabs.org>
>>     http://lists.sugarlabs.org/listinfo/sugar-devel
>     _______________________________________________
>     Sugar-devel mailing list
>     Sugar-devel at lists.sugarlabs.org
>     <mailto:Sugar-devel at lists.sugarlabs.org>
>     http://lists.sugarlabs.org/listinfo/sugar-devel
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20151224/a0408a9a/attachment-0001.html>

More information about the Sugar-devel mailing list