[Sugar-devel] #2963 UNSP: Sugar telepathy code does not take into account presence status of buddies
alsroot at activitycentral.org
Sat Jul 16 09:24:03 EDT 2011
On Sat, Jul 16, 2011 at 01:34:21PM +0100, Daniel Drake wrote:
> On 16 July 2011 12:44, Aleksey Lim <alsroot at activitycentral.org> wrote:
> > 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 .
> I must have missed the announcements then. Apologies. (I still can't
> find them after searching the archives)
hmm, it seems to be in school server related threads and not all posts
are on ML, sorry then. Though, in my mind jabber.sl.o was in semi-productoin
state (after not working for a couple of weeks and every day crashes)
and I wasn't thinking about announcing its development process except
urgent maitaining cases. So, it is a good reason to start doing that.
> I am in full support of experimenting with alternative jabber
> implementations, I think that's great and am excited by your work. I
> just don't think you should do it so quietly, uncollaboratively, and
> on the server that sugar connects to by default.
> I also think that your arguments against ejabberd are shallow and
> uninformed - suggesting that it can't handle thousands of users just
> shows ignorance in the face of the large ejabberd servers that are out
> their in production.
you missed my words about sugar server workflow (it is exactly targeting
to up to 1K users by design), and that amount of users is ok for
jabber.sl.o as well (we don't hanve more than 30-40 online users there).
> I know it can be hard to get to grips with the
> unconventional design, but time and code investment in solving the
> issues that you are facing with ejabberd would be a much less
> intrusive fix for our existing users. (not that I want to discourage
> experimentation with alternative servers which of course may turn out
> to be better in the long run. it may even be less mind-boggling, which
> would be great.)
once more, prosody related work started exactly for limited usecase
(1K users and as less maintaning as possible, both reasons ok for
current jabber.sl.o), and I don't see any reasons why not having tools
(that are work best-of-all) for one particular use case and having
several of them for <1K (prosody) and >1K (ejabberd).
More information about the Sugar-devel