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 >>>> <[email protected]> wrote: >>>>> >>>>> On 30 May 2012, at 14:13, Kevin Smith wrote: >>>>> >>>>> On Wed, May 30, 2012 at 2:09 PM, Theo Cushion >>>>> <[email protected]> wrote: >>>>> >>>>> >>>>> On 30 May 2012, at 13:21, Kevin Smith wrote: >>>>> >>>>> >>>>> On Wed, May 30, 2012 at 1:13 PM, Theo Cushion >>>>> <[email protected]> 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: >>>>> "[email protected]" >>>>> >>>>> 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 = "[email protected]" node = "users" - jid = >>>>> "[email protected]" node = "messages" - jid = >>>>> "[email protected]" node = "subject" >>>>> >>>>> (I don't think this will conflict with anything?) >>>>> >>>>> If I want to receive all events in Pubsub form I subscribe to >>>>> "[email protected]". If I just want the messages and >>>>> users I can subscribe to "[email protected], users" >>>>> and "[email protected], 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! _______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
