On Wed, May 30, 2012 at 10:43 AM, Theo Cushion <t...@jivatechnology.com> wrote: >> Where are you seeing the performance problems with having many MUCs? >> It should make no odds to a client that it's present in many empty >> MUCs (although I guess if you're talking about thousands, the number >> of join stanzas would get onerous), and servers are likely to scale >> well (empty MUCs will be using almost no resources). > The performance issue is in the client, every time we have a new connection > it has to send a whole bunch of join stanzas. This may not sound like a big > deal, but it causes a noticeable delay in all of the processing that has to > be done when a page is first loaded.
Well, golly, I'm amazed. How many rooms are we talking about? > I imagine we are a fairly isolated in our application wanting clients to auto > join rooms every time they connect, so there's no point in addressing this in > the standard. However, linking in with the Muc/Pubsub (MEP?) could provide a > great way to get around this issue, and be universally useful. Well, most desktop clients are set to autojoin a bunch of rooms... > What do you think? So the problem is only needing one class of user to be joined to specific MUCs when someone from another class of user joins one? There's a potential here (you control all clients, don't you?) to have an intermediary know when class B users join a MUC so they can then send invites to the appropriate class A users. /K _______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org _______________________________________________
