Hi, >Right. If you send a non-MUC enabled presence an unlocked instant room >should be created for you if one does not exist. At least that's how I >understand it (and how we implemented it as well).
Since I am sending always a MUC-free <presence/>, I suppose the "bug" is that "some" unlocked instant rooms are locked accidently. Not as we supposed before, that most locked rooms are accidently unlocked. Question would then be how the component would "fall" into the room locking fork instead of leaving it unlocked-instant? Is there any way to configure in the config file that only unlocked-instant rooms will be created? I will try to reproduce the case but seems to be difficult. Most of my rooms work. Happens only sometimes. hw -- Dr. Heiner Wolf bluehands GmbH & Co.mmunication KG http://www.bluehands.de/people/hw +49 (0721) 16108 75 -- Jabber enabled Virtual Presence on the Web: www.lluna.de Open Source Future History: www.galactic-developments.de >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf >Of JD Conley >Sent: Wednesday, September 28, 2005 8:06 PM >To: Jabber software development list >Subject: RE: [jdev] MU-Conference returning "Not Found" > > >> My goal is very simple: send a <presence/> to create an open room >where >> everyone can join. >> >> Maybe the fact that is usally works is a bug. > >It sounds like it to me. > >> >> I was thinking that MUC is backward compatible to GroupChat. >If I send >a >> <presence/> without any mentioning of MUC, then I should get a room >> which is not locked until it is configured. > >... > >> No <x xmlns='http://jabber.org/protocol/muc'/>, no locking, right? > >Right. If you send a non-MUC enabled presence an unlocked instant room >should be created for you if one does not exist. At least that's how I >understand it (and how we implemented it as well). > >-JD >
