[jdev] Minimising number of MUC rooms

Wed May 30 16:12:52 UTC 2012

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

Peter

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