Re: [Sugar-devel] Current status of collaboration work
Hi Tony,
On Thu, Dec 24, 2015 at 5:35 PM, Tony Anderson
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)
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.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-t
Re: [Sugar-devel] Current status of collaboration work
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
> 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
*Conclu
Re: [Sugar-devel] Current status of collaboration work
Hi Martin, On Thu, Dec 24, 2015 at 6:52 AM, Martin Abente < 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?* > > 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@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] wiki down?????
The page is unchanged. But it has a reference to a document that seems
broken:
{{#widget:Google Spreadsheet
|key=0AhHzhQAGOPDfdFFhcU9CdUZWWVpMaWJVUDJ3c3pFM0E
|width=400
|height=1200
}}
On Wed, Dec 23, 2015 at 3:00 PM, James Cameron wrote:
> The member list is not shown.
>
> See attached screenshot; Firefox on Ubuntu 14.04.
>
> --
> James Cameron
> http://quozl.netrek.org/
>
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Current status of collaboration work
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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] wiki down?????
looks OK to me. On Wed, Dec 23, 2015 at 2:23 PM, samson goddy wrote: > Hello All > > It has come to my notice that the wiki page that allow users to see the > members in sugar labs is no longer working > https://wiki.sugarlabs.org/go/Sugar_Labs/Members/List > > -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] wiki down?????
Hello All It has come to my notice that the wiki page that allow users to see the members in sugar labs is no longer working https://wiki.sugarlabs.org/go/Sugar_Labs/Members/List ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
