[Sugar-devel] Thoughts on Collab

[Tony Anderson]

The 'patch' was essentially  to place every ejabberd client in the same 
group. AFIK, there is no
strong reason not to upgrade ejabberd on the server side to a current 
release. I don't have the information
at hand but we were working with a group with focus on collaboration who 
implemented the patch - perhaps someone
remembers the group and how we could interact with them again.

There are client-side software implementations available for XMPP: 
https://github.com/Jajcus/pyxmpp2 as an example. My guess is the 
collab-wrap could support XMPP without a lot of other dependencies.

Tony

On 07/24/2016 10:09 AM, Jerry Vonau wrote:
>
>> On July 23, 2016 at 5:36 PM sam at sam.today wrote:
>>
>>
>> Hi All,
>>
>> In the irc meeting 2 nights ago, we discussed adding collaberation to
>> the journal project feature.  Abhijit has spent around 3 weeks working
>> on it.  But we can't even get a text channel between the participants.
>> Telepathy is painful, buggy (we have a segfault in salut) and hard to
>> debug.  It is also unmaintained - the last commit to telepathy salut
>> and gabble was 2 years ago.
>>
>> So this is the pre-text for an experiment; modernising the
>> collaboration stack without using telepathy.
>>
>> Initially, I proposed Matrix.Org.  I don't support this idea any more,
>> as matrix.org has some very messaging specific features, and some spots
>> where sugar would not fit idiomatically within the api.
>>
>> So I have been thinking a little more about splitting up the problem
>> into 3 sections:
>>
>> 1)  A neighbourhood view implementation - a model to discover people
>> nearby or via the school server
>> 2)  A group messaging socket - the backbone for collaboration in
>> activities
>> 3)  A one-to-one file transfer mechanism - used for initial state sync
>> in activities, "send to" feature in journal, etc
>>
>> I have think that we can do the neighbourhood view by using 2 backends
>> and merging the result.  We can use the Avahi api to publish/find
>> activities/buddies on the local network.  We could additionally use a
>> school server (running a custom sugar server app) to support buddies
>> who are not on the same network.  Since both activities and buddies
>> have unique identifiers, we can easily have both back-ends running at
>> the same time, and de-duplicate the result.
>>
>> Avahi is very fun to work with:
>>
>>      avahi-publish-service "Sam P" "_org_sugarlabs_collab_user._tcp"
>> 8080 "name=Sam P" "color=#fff,#000" "other_metadata=other_value"
>>      avahi-discover
>>
>> All of the backends could give us an ip and a port to reach the other
>> person.  For the avahi backend, this would be a direct connection to
>> the other buddy.  For the schoolserver, it would be proxied through the
>> schoolserver.
>>
> FWIW, I plan on dropping support for gabble within XSCE as the code base is
> very old and I'm not fond of maintaining the fork, with OLPC's patch, of
> ejabberd. The only reason I have not done so yet is that the package still
> installs but nobody is testing the functionality. Should the server side
> get updated and straitened out I would welcome keeping ejabberd in the XSCE
> fold. Just don't look to have the XSCE project help with the development of
> the updating, but testing of the updated server side we might help with as
> I can't speak for everybody involved. Pull requests welcome.
>
> Jerry
>
>
>> I'd love to hear your thoughts on the other problems, and on this
>> problem to.
>>
>> Thanks,
>> Sam
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel