[jdev] Minimising number of MUC rooms

[Peter Saint-Andre]

On 5/30/12 7:28 AM, Kevin Smith wrote:
> On Wed, May 30, 2012 at 2:27 PM, Theo Cushion <theo at jivatechnology.com> wrote:
>>
>> On 30 May 2012, at 14:13, Kevin Smith wrote:
>>
>> 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
>>
>>
>> I think we're on the same page. I'll try and illustrate with an example:
>>
>> We have a normal MUC room residing here: "heath at chat.shakespeare.lit"
>>
>> However, we also have a Pubsub root node living at the same address, then we
>> have a number of predefined children nodes,  for sake of argument (I guess
>> advertised using the disco features):
>>
>> - jid = "heath at chat.shakespeare.lit" node = "users"
>> - jid = "heath at chat.shakespeare.lit" node = "messages"
>> - jid = "heath at chat.shakespeare.lit" node = "subject"
>>
>> (I don't think this will conflict with anything?)
>>
>> If I want to receive all events in Pubsub form I subscribe to
>> "heath at chat.shakespeare.lit". If I just want the messages and users I can
>> subscribe to "heath at chat.shakespeare.lit, users" and
>> "heath at chat.shakespeare.lit, messages" respectively. Or I could request
>> certain items, using normal pubsub messages.
>>
>>
>> It gives me the power of Pubsub, and the advantages of MUC without
>> introducing a load of baggage. Just as we represent some of this information
>> using Disco (who's in a room, subject, etc) we are doing the same for
>> Pubsub, except we are doing it in a push fashion.
>>
>> Any merit?
> 
> It's an interesting idea, and it does address your use case quite
> nicely. I wonder what other people think?

Well, you know, everything is pubsub. ;-)

If we had started in 1999 with just pubsub, then MUC would have been
simply a special instance of pubsub along the lines that Theo has
described. I see no harm in offering a pubsub interface to the same data
that flows through the MUC room. One possible glitch is destroying the
room -- that can be done with one atomic command in XEP-0045, but in
pubsub you'd need to delete all of the nodes at the same time, and we
don't have an atomic command for that in XEP-0060. As long as the MUC
room/address is primary then I think this can be handled via MUC (with
pubsub being an alternative interface to the same data).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/