On Sat, Jul 16, 2011 at 10:04:12AM +0100, Daniel Drake wrote: > On 13 July 2011 21:52, Aleksey Lim <alsr...@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@. 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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel