[Sugar-devel] #2963 UNSP: Sugar telepathy code does not take into account presence status of buddies

[Aleksey Lim]

On Sat, Jul 16, 2011 at 10:04:12AM +0100, Daniel Drake wrote:
> On 13 July 2011 21:52, Aleksey Lim <alsroot at activitycentral.org> wrote:
> > Ok. Though, my point is that jabber.sl.o uses preliminary prosody sugar
> > plugin and I'm improving it right now (and sugar code as well, will post
> > patches). Will setup jabber-devel.sl.o then.
> 
> Oh, now that's the first I've heard of that. So you ditched ejabberd,
> changed to a new jabber server, added your own (unpublished?
> unreviewed? experimental?) code, and didn't announce the change? All
> this on the server that Sugar installations connect to by default?

If you mean not announceuncing for using on jabber.sl.o..
Well, I started working w/ jabber serve side after that jabber.sl.o was
down for a couple of weeks and nobody had a time to fix it. Then, after
starting 0.9x extensive usage, ejabberd managed (configured according to
wiki.l.o and using recent fc14 packages) managed to eat 4G of RES in 10h
using bunch of CPU. At the same time I started working on Sugar Server
and found that Prosody had more startup (exclusing existed for years
sugar support in ejabberd) benefits for sugar server case (up to 1K
users, low mem and cpu usage).

Since jabber.sl.o is targeiting for dev use cases and the fact that
everyday resetting (/usr/share/ejjaberd) ejabberd data is not enough to
prevent kernel killing apps due to lack of memory, I installed prosody
for jabber.sl.o. Both events were announced on sugar-devel at .

For my own, I found prosody much useful (for a person who are not
familiar w/ lua and eralng and w/ code base of both jabber servers) for
developing (all jabber features are formed as plugins and it is very
simple to undestand for it works and reuse code for sugar plugins) and
for testing (2s of compiling, 1s for running from sources dir by
./prosody). And I'm sure that during system testing of Sugar Sever
infra, Prosody will be show better results (for sugar server use case)
than ejabberd.

> My points regarding having an extreme case test server still stand -
> but knowing that this is a server misconfigured at the code level
> change my opinion. We have better ways to spend our time. With this in
> mind I'd recommend reverting jabber.sugarlabs.org back to what it was
> before, and running your own experiments on servers with other names.

The thing is simple, as I said I started working on jabber server when
it was down for a couple of weeks. And since that time I'm working on
jabber.sl.o infra. And my strong vision is that sugar (exactly client
side, not SugarOS or XS) should behave in standard way w/ a jabber
server and having not only one ejabberd server is a right way in that
direction.

> 
> Daniel
> 

-- 
Aleksey