[Sugar-devel] Current status of collaboration work

[Sam P.]

Hi Gonzalo,

I agree with your perspective that we do need to make the wrapper the best
it can be before locking ourselves into it.  That is a good plan.

I'm not sure what you mean about adding a parameter to the setup method.
Could you please elaborate?

Thanks,
Sam

On Sat, Dec 26, 2015 at 10:55 AM, Gonzalo Odiard <godiard at sugarlabs.org>
wrote:

> Hi Martin,
> I like your proposal of use the wrapper in the activities by at least one
> cycle, before include it in the toolkit.
> In our experience, once the code is included in the toolkit, is difficult
> make changes without breaking activities in
> unexpected ways.
> I didn't have time to make tests with the wrapper, and is really difficult
> do tests for collaboration. We have seen
> bugs that appear only when you have many computers, or using jabber but
> not when using the mesh, etc.
> I think the wrapper is a very, very good start (Thanks Sam and Walter) and
> even they provided patches for some activities.
> Sadly, some of the activities are on my hands, but I didn't have time the
> last months to do the proper testing
> and integration of the patches.
> About the wrapper API, just looking at the code, I think would be better
> add a callback parameter to the setup() method
> because the initialization is async and then is the only way to execute
> your activity code when the initialization
> has finished. Issues like this are difficult to get right at the first
> time.
> I know I am not doing almost any work in sugar these months, don't take
> these comments as a critic,
> just as a way to try to help, and avoid problems in the future.
> Regards,
>
> Gonzalo
>
>
>
> On Wed, Dec 23, 2015 at 4:52 PM, Martin Abente <
> 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?*
>>    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.
>>    3. Cleanup the Wrapper and make sure that it is possible to use it
>>    locally in activities.
>>
>> *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]
>>
>> *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
>>
>
>
>
> --
> Gonzalo Odiard
>
> SugarLabs - Software [for | by] children learning
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20151226/35dc147e/attachment.html>