<P>
  <BR>
 Hi .<BR>
  Is there any way (under current implementation), to get the names of persistent chatrooms created by me (earlier). wherein i want to destroy the room. <BR>
  Kindly let me know, how is that possible.<BR>
 Thanks,<BR>
   Kawaljeet.<BR>
<BR>
<BR>
On Tue, 15 Apr 2008 Peter Saint-Andre wrote :<BR>
>Matthew Wild wrote:<BR>
> > On Fri, Apr 11, 2008 at 10:23 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:<BR>
> >  >  Registered with the room or with the service? Do we need to<BR>
> >  >  differentiate between the two? If you are registered with the room then<BR>
> >  >  you are a member, whereas nick registration has meaning across the<BR>
> >  >  service. Compare Section 7.10 of XEP-0045, where you register with the<BR>
> >  >  room, to registration with the service.<BR>
> >  ><BR>
> ><BR>
> >  Good question... the problem I see is that all this is very<BR>
> >  implementation dependent. ejabberd at least doesn't allow you to<BR>
> >  register a nick in a room, and it isn't explicitly specified in the<BR>
> >  XEP (which says the server can send a data form).<BR>
> ><BR>
> >  If you are a room member, this is visible already anyway, so I am<BR>
> >  edging towards registration with the whole service (unless we<BR>
> >  implemented both).<BR>
><BR>
>Yes I think that makes sense.<BR>
><BR>
> >  >  > The reason I believe this is needed is because the lack of it makes nick<BR>
> >  >  > registration fairly useless in anonymous rooms. If someone can see<BR>
> >  >  > that a user's nick is registered, they have a certain level of<BR>
> >  >  > assurance that the next time they see this nick, it is the same<BR>
> >  >  > person. Without this knowledge it may as well be someone completely<BR>
> >  >  > different.<BR>
> >  >  ><BR>
> >  >  > Currently I don't believe there is any way to tell, which means that<BR>
> >  >  > even if you register your nick on a service, it provides little<BR>
> >  >  > benefit (unlike it would on IRC/NickServ).<BR>
> >  ><BR>
> >  >  The only way to tell is by trying to register the nick yourself. And<BR>
> >  >  that seems rather silly. :)<BR>
> >  ><BR>
> ><BR>
> >  Ah yes, there is that (a method I have used before, and even<BR>
> >  considered adding to HAL as a hacky workaround).<BR>
><BR>
>HAL knows all...<BR>
><BR>
> >  >  I see two approaches:<BR>
> >  ><BR>
> >  >  1. If someone is registered, the service includes a flag in their<BR>
> >  >  presence broadcast -- something like the following:<BR>
> >  ><BR>
> >  >  <presence<BR>
> >  >     from='darkcave@macbeth.shakespeare.lit/thirdwitch'<BR>
> >  >     to='crone1@shakespeare.lit/desktop'><BR>
> >  >   <x xmlns='http://jabber.org/protocol/muc#user'><BR>
> >  >     <item affiliation='member' role='participant'/><BR>
> >  >   </x><BR>
> >  >   <registered xmlns='urn:xmpp:mucserv'/><BR>
> >  >  </presence><BR>
> >  ><BR>
> ><BR>
> >  Seems ok...<BR>
> ><BR>
> >  >  2. The service enables you to check if someone is registered:<BR>
> >  ><BR>
> >  >  <iq from='crone1@shakespeare.lit/desktop'<BR>
> >  >     id='check-nick-1'<BR>
> >  >     to='macbeth.shakespeare.lit'<BR>
> >  >     type='get'><BR>
> >  >   <registered xmlns='urn:xmpp:mucserv'><BR>
> >  >     thirdwitch<BR>
> >  >   </registered><BR>
> >  >  </iq><BR>
> >  ><BR>
> >  >  If the nick is registered, the service returns an IQ-result, otherwise<BR>
> >  >  it returns an error (<item-not-found/> if the nick is not registered,<BR>
> >  >  <service-unavailable/> if the protocol is not supported):<BR>
> >  ><BR>
> >  >  <iq from='macbeth.shakespeare.lit'<BR>
> >  >     id='check-nick-1'<BR>
> >  >     to='crone1@shakespeare.lit/desktop'<BR>
> >  >     type='result'/><BR>
> >  ><BR>
> >  >  OR<BR>
> >  ><BR>
> >  >  <iq from='macbeth.shakespeare.lit'<BR>
> >  >     id='check-nick-1'<BR>
> >  >     to='crone1@shakespeare.lit/desktop'<BR>
> >  >     type='error'><BR>
> >  >   <error type='cancel'><BR>
> >  >     <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/><BR>
> >  >   </error><BR>
> >  >  </iq><BR>
> >  ><BR>
> >  ><BR>
> ><BR>
> >  Also ok...<BR>
> ><BR>
> >  I'm wondering which would be more convenient from a client UI perspective.<BR>
> ><BR>
> >  A new element in presence is a new overhead, but if you want to know<BR>
> >  up-front who is registered, we don't want clients to have to query<BR>
> >  each user in every MUC they join.<BR>
> ><BR>
> >  In my use case I don't mind querying (I only want to know about people<BR>
> >  I interact with) and the same for HAL's use case (checking that the<BR>
> >  user is the same person, when he isn't in a position to know their<BR>
> >  JID).<BR>
><BR>
>If we don't include it in presence, clients will query everyone. I think<BR>
>I'd prefer the presence flag.<BR>
><BR>
>Peter<BR>
><BR>
>--<BR>
>Peter Saint-Andre<BR>
>https://stpeter.im/<BR>
><BR>

</P>


  -- kawaljeet singh chadha <br>
<br>
Here is the test to find whether your mission on Earth is finished: if you're alive, it isn't ... <br>
<br><br>
<Table border=0 Width=644 Height=57 cellspacing=0 cellpadding=0 style='font-family:Verdana;font-size:11px;line-height:15px;'><TR><td><img src ='http://imadworks.rediff.com/cgi-bin/AdWorks/adimage.cgi/2087310_2079844/creative_2087453.jpg'  alt='JS RED'  border=0></td></TR></Table>