[Sugar-devel] Current status of collaboration work

[Tony Anderson]

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?

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'.

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.

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
> http://lists.sugarlabs.org/listinfo/sugar-devel

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