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@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@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
