[jdev] Minimising number of MUC rooms

[Theo Cushion]

On 30 May 2012, at 17:12, Peter Saint-Andre wrote:

> On 5/30/12 9:02 AM, Theo Cushion wrote:
>> 
>> 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.
> 
> I don't particularly think that we need an upgrade path from MUC itself,
> but having a pubsub layer on top of it or to the side would enable us to
> do some creative things in the context of MUC. Your idea of arbitrary
> nodes in the same space is part of what drove interest in "MEP" from the
> beginning.
> 
> It sounds to me as if you might want to experiment with this in your
> preferred server codebase to see what is possible. :)

Will do!