<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "> <div><div>On 30 May 2012, at 14:13, Kevin Smith wrote:</div> <blockquote type="cite"><div>On Wed, May 30, 2012 at 2:09 PM, Theo Cushion <<a href="mailto:theo@jivatechnology.com">theo@jivatechnology.com</a>> wrote: <blockquote type="cite"> </blockquote><blockquote type="cite">On 30 May 2012, at 13:21, Kevin Smith wrote: </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite"><blockquote type="cite">On Wed, May 30, 2012 at 1:13 PM, Theo Cushion <<a href="mailto:theo@jivatechnology.com">theo@jivatechnology.com</a>> wrote: </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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. </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I'm not sure there's a silver bullet that'll solve all your problems </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">trivially - but I'm also not sure that there isn't a solution that </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">gains you more than what you currently propose. </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">So, there are two things being discussed here: </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">1) Your use case and the need to limit the work done by the client on </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">login. I think this is addressable for your deployment by limiting the </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">number of rooms that need to be joined prior to there being activity </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">in them (or possibly by using pubsub nodes rather that MUC rooms, </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">although this is not a clear win and requires you to do significantly </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">more client work). </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">2) Allowing servers to 'force' or 'autojoin' users into MUCs - this is </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">a feature that's generally interesting and speccing it up seems </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">sensible even if it won't help your cases (although it might, in </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">combination with some new server code). </blockquote></blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">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. </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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. </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Right, it is. </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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? </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">It'll receive presence from anyone in the room (I've not counted this) </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">its own presence (I did count this), any message history </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">requested/sent (I've not counted this) and the room subject, which </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">indicates the join is complete (I did count this). </blockquote></blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">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. </blockquote> 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 </div></blockquote> </div><div>I think we're on the same page. I'll try and illustrate with an example: We have a normal MUC room residing here: "<a href="mailto:heath@chat.shakespeare.lit">heath@chat.shakespeare.lit</a>" 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 = "<a href="mailto:heath@chat.shakespeare.lit">heath@chat.shakespeare.lit</a>" node = "users" - jid = "<a href="mailto:heath@chat.shakespeare.lit">heath@chat.shakespeare.lit</a>" node = "messages" - jid = "<a href="mailto:heath@chat.shakespeare.lit">heath@chat.shakespeare.lit</a>" node = "subject" (I don't think this will conflict with anything?) If I want to receive all events in Pubsub form I subscribe to "<a href="mailto:heath@chat.shakespeare.lit">heath@chat.shakespeare.lit</a>". If I just want the messages and users I can subscribe to "<a href="mailto:heath@chat.shakespeare.lit">heath@chat.shakespeare.lit</a>, users" and "<a href="mailto:heath@chat.shakespeare.lit">heath@chat.shakespeare.lit</a>, 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? Theo</div> </body></html>