Hi Guys, Can I know the procedure of creating a room please, I'm searching for it day long please help and do we have the delegate methods of creating a room and do other functions too... Please help me in taking a start in creating a room thank you.
On Mon, Oct 22, 2012 at 10:38 PM, Daniel Dormont <[email protected]>wrote: > > On Fri, Oct 12, 2012 at 12:15 PM, Waqas Hussain <[email protected]> wrote: > >> On Fri, Oct 12, 2012 at 7:39 PM, Daniel Dormont >> <[email protected]> wrote: >> > Hi all, >> > >> > In my XMPP application, users can exchange both private messages and >> > presence and join MUCs. Ok, simple enough. I've implemented invisibility >> > according to XEP-0126. I'd like the users to be still able to join MUCs >> > while invisible, though. The issue I'm running into is that the first >> step >> > in going invisible is sending an unavailable presence for broadcasting >> to >> > all contacts: <presence type='unavailable'/> >> > >> > Unfortunately for me, this has the additional effect of kicking the >> user out >> > of any MUCs they'd joined in that particular session. I've already >> figured >> > out how to tweak the privacy list so users can join MUCs while >> invisible to >> > individual contacts, basically it just looks like >> > >> > <list name='invisible'> >> > <item type='jid' >> > value='conference.mydomain' >> > action='allow' >> > order='1'> >> > <presence-out/> >> > </item> >> > <item action='deny' order='2'> >> > <presence-out/> >> > </item> >> > </list> >> > >> > But I'm running into this problem when the user tries to go "globally" >> > invisible while already in one or more MUCs. Is there any way around >> this? >> > My initial thought was to direct the unavailable presence to only the >> > primary (IM) domain rather than having no "to" as indicated in the XEP, >> but >> > that doesn't seem to broadcast to anybody, so contacts who already >> thought >> > the user was online will continue to think so. >> > >> > Is there any way around this? Or will I have to change my approach to >> > invisibility? >> > >> >> Blocking out-going presence to the chatrooms before you send >> unavailable presence might work. This is a hack which depends on the >> server not sending unavailable presence to blocked contacts. >> >> Directed presence is almost completely separate from normal presence >> status, with this one exception: unavailable presence broadcasts. I'm >> beginning to think this is more harmful than helpful. >> >> Relevant spec section: http://tools.ietf.org/html/rfc6121#section-4.6.3 >> >> > I think I need some more time to digest that section. There's something I > still don't quite follow about it. But in the mean time, your trick of > temporarily employing a privacy list that's the exact opposite of the > normal invisibility one, worked fine, so thanks. > > dan > > > >> > thanks, >> > Dan >> > >> >> -- >> Waqas Hussain >> _______________________________________________ >> JDev mailing list >> Info: http://mail.jabber.org/mailman/listinfo/jdev >> Unsubscribe: [email protected] >> _______________________________________________ >> > > > _______________________________________________ > JDev mailing list > Info: http://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: [email protected] > _______________________________________________ > >
_______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
