[jdev] Minimising number of MUC rooms

[Theo Cushion]

On 30 May 2012, at 15:41, Peter Saint-Andre wrote:

> 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. ;-)

Yes, I really like things like the standards such as PEP which add a bit of convention over configuration to a very powerful mechanism. It gives some great use cases and doesn't reinvent the wheel.

> 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).

Yes, I imagine the Pubsub layer to be a kind of readonly layer on top of the MUC info. This would minimise the possibility of any edge cases and provide most of the benefit.

The exception to this would be creating arbitrary nodes within the same space (can of worms?). For instance, an occupant might want to create a node and start publishing arbitrary information that makes sense to be linked with the MUC room. I think this might be what some other threads are getting at.

I remember the general consensus at FOSDEM this year was that MUC isn't what it could be (not to discredit all of the hardwork that has gone into it). Looking at the broader picture, do you think having a Pubsub layer such as this on top could provide a sensible upgrade path? The operation of a MUC room remains the same, but we can start getting the benefits of modelling it using Pubsub.

More fuel for the fire!