[Sugar-devel] [Server-devel] notes on scaling ejabberd for the XO's
michael at laptop.org
Tue Mar 17 19:53:59 EDT 2009
On Sun, Mar 15, 2009 at 06:30:17PM -0400, Daniel Drake wrote:
>2009/3/15 Martin Langhoff <martin.langhoff at gmail.com>:
>> "Client" code for Gadget seems to be integrated in the Telepathy new
>> Sugar present on the SoaS images. The server side -- the proper gadget
>> code -- isn't on any XS, and I haven't seen or tested it (lack of time
>> :-( )
>> Even if I had, it's a ton of new code, a lot more adventurous than
>> what we're doing w moodle. So short/midterm, following ejabberd+moodle
>> is lower risk from the perspective of a deployment today.
>One thing I still don't understand about gadget... how does it
>actually solve the problem? I'm assuming the problem it solves is lack
>of partitioning, and the fact that the neighborhood view becomes kind
>of impossible after 50 users, etc. Right?
Wrong. Gadget is primarily intended to reduce the bandwidth consumed by Gabble
under the load generated by Sugar.
>So what does gadget do?
Think of it as a server-side keyword search engine which you can query for
lists of matching people and activities. The purported bandwidth reduction
comes from sending each client only what it asks for instead of everything,
which is what the shared roster hack does.
>Is there a new client side UI for electing groups? Who chooses, the kids or
>the teachers? etc.
eight months ago but the absence of comments in that ticket and the current
paucity of results in
suggests to me that the Sugar folks have completely ignored the necessary UI
work in favor of more pressing issues.
To understand how Gadget works, read
and skim the contents of
paying particular attention to the automated tests. Then, if you're feeling
brave, read the Gabble source code:
paying particular attention to the files whose names contain 'olpc'.
More information about the Sugar-devel