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.lah...@gmail.com
<mailto:martin.abente.lah...@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
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
<mailto:Sugar-devel@lists.sugarlabs.org>
http://lists.sugarlabs.org/listinfo/sugar-devel
