On 5/30/12 7:28 AM, Kevin Smith wrote: > On Wed, May 30, 2012 at 2:27 PM, Theo Cushion <t...@jivatechnology.com> wrote: >> >> On 30 May 2012, at 14:13, Kevin Smith wrote: >> >> On Wed, May 30, 2012 at 2:09 PM, Theo Cushion <t...@jivatechnology.com> >> wrote: >> >> >> On 30 May 2012, at 13:21, Kevin Smith wrote: >> >> >> On Wed, May 30, 2012 at 1:13 PM, Theo Cushion <t...@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: "he...@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 = "he...@chat.shakespeare.lit" node = "users" >> - jid = "he...@chat.shakespeare.lit" node = "messages" >> - jid = "he...@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 >> "he...@chat.shakespeare.lit". If I just want the messages and users I can >> subscribe to "he...@chat.shakespeare.lit, users" and >> "he...@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/ _______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org _______________________________________________
