Really thanks a lot for all the feedback, let me tell you that this is one of the best feedback I`ve received in a while, congratulations. I`ll be telling you about this when I look at this. Bye Andres Nacelle. <div class="gmail_quote">2009/8/14 Benjamin M. Schwartz <<a href="mailto:bmschwar@fas.harvard.edu">bmschwar@fas.harvard.edu</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im">Andrés Nacelle wrote: > We've got good results with the ejabber, but we don't know what > will happen in a big school where 200 or 300 XO may appear n the > Neighbourhood view. </div>Two solutions have been developed for this problem. Both work by making sure that each user does not see all 300 other users. 1. Collabora's Gadget. Gadget is a Jabber extension that can be run with ejabberd. It modifies the visibility/roster behaviors so that each user only sees a restricted number of other users. Who sees who can be configured programmatically, or even made to be random. 2. Moodle's ejabberd integration. Martin Langhoff developed a system to connect Moodle's concept of classes to ejabberd. The result is that each user only sees other users in his/her class, as configured through the Moodle web interface. I'll propose a third option, while we're talking about it: 3. Per-class servers. You can run many different ejabberd instances, with DNS names like year4classD.schoolserver.local, one for each classroom. Users can connect to the one for their classroom. Even if all the ejabberds are running on the same physical server, this would prevent overload. Once the servers are set up, no further server-side configuration is required, and users can choose which class they are in. --Ben </blockquote></div>