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

[Aleksey Lim]

On Mon, Jul 18, 2011 at 03:00:54AM -0700, Sameer Verma wrote:
> On Sat, Jul 16, 2011 at 6:24 AM, Aleksey Lim
> <alsroot at activitycentral.org> wrote:
> > 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).
> >
> 
> I don't see the point in having two different server implementations
> for two different use cases, where the only difference is volume. If
> ejabberd works for > 1K, it should be a good candidate for < 1K as
> well. I have ejabberd running on a XO-1 via XS 0.6 (running on a class
> 6 SD card) and for a small pool of users (25 to 30) it works just
> fine.

Well, actually I'm not sure what we are arguing about. Though, I
personally didn't had such intention, ie, I didn't have intention to say
"Lets, ie, every developer/supporter switch to Prosody from ejabberd" or
"Lets, ie, every developer/supporter support also Prosody", just said that
I see benefits for Prosody against ejabberd for me (see below)). The point
is simple, if people use/do something, they see benefits for that (people
who do the same in different way, see benefits for that as well).

My own benefits for using Prosody are:

* being not familiar w/ lua or erlang and not familiar w/ codebase of
  Prosody and ejjaberd, I found that:
* learning the code of Prosody is easier than ejjaberd
* for sugar server (up to 1K scenario), Prosody is more preferable
  (regardless sugar support):
  * Lua/C vs. erlang
  * sugar server scenario assumes as less as possible of any maintaning
    needs; just an example, having fedora packages prepared by olpc
    people and instructions from olpc wiki + 0.9x code, I got on
    jabber.sl.o the situation when kernel started killing process on 6G
    system, just installing Prosody and adding jabber setting from
    ejjaberd olpc wiki, for the same amount of time it took 1G (thats
    not an indicative example but just a glimpse of how two servers
    treating free resources); before intensive 0.9x usage, I had to
    reset ejabberd (remove all users) because having 2K of fake users
    tended ejabberd to eat 100+% of cpu and 4G of memory, at the same
    time current Prosody (w/ the same 0.9x clients) took 300M and much
    less cpu for 2 weeks;
    btw about how many server eats, it depends on the use case, ie,
    right after start, Prosody take 5M :)
    So, for me Prosody shows that it much humble (in potential) for
    consuming resources and more bullet proof for maintaning to start
    thinking about using it, thus I did it.
* for now, I don't see critical problems w/ adding sugar support to
  Prosody - it took a week to implement initial support (that is running
  on jabber right now, if you are getting problem like dups in F1 view,
  swee [SWEETS] post here)

If we are talking about sugar server context, I'm not sure that if every
one who working with school servers got the major idea for sugar server,
my own intention to use Prosody for deployments I will take part in,
does not have direct relations with sugar server, ie, sugar serve is *abs*
not about providing final solution as OLPC XS does, but a bunch of tools
to use on purpose. The Prosody is one of such tools withing sugar server
initiative.

-- 
Aleksey