[Sugar-devel] Thoughts on Collab
tony_anderson at usa.net
Sun Jul 24 04:20:19 EDT 2016
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.
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
>> 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"
>> 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
> 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.
>> I'd love to hear your thoughts on the other problems, and on this
>> problem to.
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
More information about the Sugar-devel