[IAEP] [sugar] Sugar Camp Cambridge 17-21 Nov

[Greg Smith]

Hi Robert,

Thanks for the details and documentation.

I pasted your comments below and a link to the sugarlabs site in to the 
synchoronous collaboration sectin here: 
http://wiki.laptop.org/go/Feature_roadmap#Synchronous_Collaboration

Eben,

I'm having trouble keeping my roadmap in synch with the sugarlabs plans. 
I didn't see this stuff on the "ideas" page listed on our XO roadmap. 
When I searched for "sugarlabs" on the 
http://wiki.laptop.org/go/Feature_roadmap I only find three items, all 
off the reliability page. Can you check the roadmap page one more time 
and make sure we are tracking everything properly?

Robert,

My basic question is: will this meet the requirements?

e.g. will it allow the following (from here with more details: 
http://wiki.laptop.org/go/9.1.0_Collaboration_Requirements)

N13 Must support up to 3 XOs using an activity and all others XOs (up to 
10) watching what happens on that screen.

N14 - Should support 10 XOs (as allowed by scale) using an activity 
simultaneously.

N15 - Nice to have all XOs as allowed by scale using an activity 
simultaneously.

N16 - Must support pairs of two XOs collaborating with each other up to 
the number of XOs supported by scale.

N17 - Should support all the partitions of XOs collaborating with each 
other (e.g. with 6 XOs, allow 2,2,2 and 3,3 and 4,1,1 etc).

N18 - Where an activity allows saving, must support saving at any time 
where the XO which saves gets a current copy of the shared file. If its 
a "save as" or "save" but not exit action then the XO which saves 
returns to the shared view. Where its an automatic "save" by leaving the 
activity, the journal must store a current copy of the shared file. All 
of these saving actions must not interfere in any way with the saved or 
shared file on the other XOs or with the collaboration or network 
connectivity of any XOs.

Maybe that is orthogonal to what you are doing, if so let me know what 
requirements you think your work will meet (aka what benefit does it 
offer the user?).

Is there anything else I should add to the requirements (e.g. must 
always be able to see all XOs visible in the neighborhood as allowed by 
scale)?

Thanks,

Greg S

Robert McQueen wrote:
> Greg Smith wrote:
>> Hi Rob,
> 
> Hi Greg,
> 
>> On this:
>> "I already added some of these above things to the roadmap wiki page as
>> things to try and improve in 9.1."
>>
>> I'm not sure I found the place where you recorded that.
> 
> Sorry for the delay, but just to connect the dots, the ideas we have at
> Collabora for the upcoming release were entered in on the SugarLabs 0.84
> wiki:
>  http://sugarlabs.org/go/DevelopmentTeam/0.84/Ideas
> 
> But they were mostly as stated in my mail, and in Guillaume's talk at
> the SugarCamp, namely:
>  * Ensure Gadget is correctly integrated and deployed in Sugar so we can
>    avoid the troublesome shared roster haxks on the XMPP server
>  * Fix tubes so that peer to peer data is sent with peer to peer
>    connections on the network where possible
>  * Fix the way JIDs are allocated to be more coherent and based on the
>    child's nickname (also would benefit a lot from having hierachical
>    DNS naming on the school server so each JID is globally unique)
>  * Expose JIDs in the UI and allow them to be typed in and approved by
>    normal subscription requests, allowing collaboration with anyone
>    whose JID you know
>  * Implement the Telepathy file transfer spec to enable that feature in
>    Sugar
>  * Enable avatars in Sugar (although maybe not if we're doing link-local
>    multicast on an XO mesh network) and maybe some UI for taking a photo
>    and setting that as your avatar
> 
>> Thanks,
>>
>> Greg S
> 
> Regards,
> Rob
>