No subject

'course' is a separate 'shared roster group'. So clients can see if
they have 3 SRGs, and can apply whatever UI to that info. Pidgin shows
it as different groups.

With this setup, there will be users you just don't see. So one thing
I am very keen on is exploring whether we can do the 'search for a
user I cannot see' via a standard XMPP call.

This is something that has been discussed re Gadget (not sure if
Gadget has it implemented) -- it will need some changes in the
'neighbourhood' UI, but will be excellent. I am sure that XMPP
supports something like that, and if ejabberd doesn't implement it, I
can implement it for the XS.

>> 3. =A0Per-class servers. =A0You can run many different ejabberd instance=
s,
>> with DNS names like year4classD.schoolserver.local, one for each

No no no. Wad was going that way, I studied the idea and it is a big
mess if you think of a real school. Teachers are active in more than
one class/group, kids often migrate class/groups. Kids may belong to
more than one class/group. Many servers is a significant cost. Using
VMs is a performance/scalability nightmare.

And to segregate each XO to a different class/group you'd need either
completely separate wifi/network infra for each class, or to maintain
MAC address tables for DHCP to assign different DNS servers to each.
Ugh!

And that's just the tip of the iceberg.

In general, it is a good idea to assume I spent a non-trivial amount
of time in my architectural decisions. :-)

cheers,



m
--=20
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff