[jdev] Minimising number of MUC rooms
Kevin Smith
kevin at kismith.co.uk
Wed May 30 13:13:04 UTC 2012
On Wed, May 30, 2012 at 2:09 PM, Theo Cushion <theo at jivatechnology.com> wrote:
>
> On 30 May 2012, at 13:21, Kevin Smith wrote:
>
>> On Wed, May 30, 2012 at 1:13 PM, Theo Cushion <theo at jivatechnology.com> wrote:
>>> I agree that there is never going to be a silver bullet that will solve all issues. However, there is always going to be a limit on the rate of stanzas that can be dealt with in a timely manner what ever the platform.
>>
>> I'm not sure there's a silver bullet that'll solve all your problems
>> trivially - but I'm also not sure that there isn't a solution that
>> gains you more than what you currently propose.
>>
>> So, there are two things being discussed here:
>>
>> 1) Your use case and the need to limit the work done by the client on
>> login. I think this is addressable for your deployment by limiting the
>> number of rooms that need to be joined prior to there being activity
>> in them (or possibly by using pubsub nodes rather that MUC rooms,
>> although this is not a clear win and requires you to do significantly
>> more client work).
>>
>> 2) Allowing servers to 'force' or 'autojoin' users into MUCs - this is
>> a feature that's generally interesting and speccing it up seems
>> sensible even if it won't help your cases (although it might, in
>> combination with some new server code).
>
> It would certainly be nice to be able to get what ever saving is possible from the standards, as then everyone can benefit rather than focusing on application specific code.
>
>>> Anything that can be done to minimise it will create more breathing room. By those estimates I'd say losing a 1/3 of the stanzas across the wire is a significant optimisation.
>>
>> Right, it is.
>>
>>> Perhaps the saving could be greater, why would there be 300+ back? If I were only the occupant, would I not just get my own presence back?
>>
>> It'll receive presence from anyone in the room (I've not counted this)
>> its own presence (I did count this), any message history
>> requested/sent (I've not counted this) and the room subject, which
>> indicates the join is complete (I did count this).
>
> Is this possibly a great fit for the Pubsub/Muc hybrid. Clients can permanently subscribe selectively to things they are interested in. For example, I don't care about room subject, but presence and history I might care about. Having this information map on to nodes to the MUC jid gives very fine control over what information is required using an existing standard. Could the Pubsub/Muc hybrid simply come down to certain predefined mappings, plus room for arbitrary information.
You mean exposing the room as both a MUC and as MEP, both being a
representation onto the same data? That would certainly help in your
case. I wonder what other people think of it?
/K
More information about the JDev
mailing list