Fundamentally, a room already exists is the situation where a room is already set up on the server with the same name as the one you wish to create.

The MultiUserChat object has a static getRoomInfo() method which may have been the way to go. If the room does not exist, return null. Instead, if the room does not exist throws an XMPPException. Not sure what the error situation is here - I am just trying to find out if a room exists or not, but that causes an exception.

The flipside is on the creation end. If you try to create a room that already exists, an XMPPException will be thrown. This makes sense and is recoverable. Still, I am a fan of checking first instead of trying to do something only to encounter a bad situation. Not a biggie - just hope this spares someone the exploration and time. Not really documented, etc.

Could not find anything to require this in the XMPP specifications for multi-user chat.

Oddness.

UPDATE:
This is apparently the way it is supposed to be according to the XMPP protocol or as explained to me on the Openfire dev boards.

1. After joining a Multi-User Chat (MUC) independently, without invite, I was forbidden (e.g. error 403) from finding out who the administrators or owners of the room were. I could not find anything about this in the documentation.
   The workaround was not too bad: apparently the method getOccupant() allows you to get an Occupant object which does hold affiliation and can report admin rights.
2. In some situations - not sure when yet - the owner of an MUC was able to grant another user admin status by just using his/her nickname, without using the full JID. That is
   grantAdmin("nickname") worked just as well as grantAdmin("nickname@conference.server"). Nonetheless, when trying to use the method getOccupant() as mentioned above, the full JID form worked while the nickname-only one failed.

I am using Smack 3.0.4 and Openfire 3.5.2. Weird.

Only thing is that JSJaC is not the easiest to set up with Openfire.

JSJaC uses HTTP-binding, which according to Wikipedia allows for long-lasting HTTP requests instead of polling, which just periodically checks the server to see if there is a message waiting. To do that, JSJaC needs to connect to the server and that is done by accessing a somewhat tricky port, 7070 is the default in version 3.5.2. What’s tricky about it? Browsers do not like to let JavaScript access services using XMLHttpRequest, the lifeblood of AJAX, on URLs and ports unlike the one which the current URL relies on. This is normally solved using a proxy or a URL rewrite, which forward requests to the desired ports and pass back responses, all as if you used the ‘appropriate’ ports. Luckily, Apache’s HTTPd has great modules that do just that. The instructions in JSJaC’s readme file recommended using a rewrite. That caused repeated 503 errors from Apache. Using its proxy did work for me. As usual, you spend time, read here and read there, and finally, you normally find a way to make it work. This how I did it.

1. After downloading JSJaC, open jsjac.js. Change the line

   var JSJACHBC_USE_BOSH_VER  = false;

   to
   

   var JSJACHBC_USE_BOSH_VER  = true;

2. To allow Apache HTTPd’s proxy to work, enable proxy_module and proxy_http_module in Apache HTTPd’s httpd.conf file
3. Add a virtual host that will map a certain URL to the proxy, and set up the proxy to point at the Openfire http-binding port:

   <virtualhost 127.0.0.1:80>
   	DocumentRoot "C:/www/root"  <!-- This is the document root for your server -->
   	AddDefaultCharset UTF-8
   	ProxyRequests On
   	ProxyPass /http-bind/ http://127.0.0.1:7070/http-bind/ <!-- This is where your Openfire server can be accessed -->
   </virtualhost>

4. To test this configuration, use JSJaC’s simpleclient.html, its sample client, to try and connect to the server. Make sure you add the following line

   oArgs.authtype = 'nonsasl';

   above

   con.connect(oArgs);

5. Start Apache HTTPd and open simpleclient.js
6. simpleclient asks for 4 fields:
   • The server’s base URL: This is the proxied URL, for example, http://127.0.0.1/http-bind/ (note the trailing slash) in my case.
   • Server name/domain: The domain Openfire was set up to use. In XMPP, if the server’s name is myserver, users will be known on it with IDs like joe@myserver
   • User name of existing user
   • The password for that user
7. Connect!

I highly recommend using Firebug to ensure the request is sent properly and is being received properly from Openfire. Odd Firefox object initialization errors are due to the fact that an attempt is made to access a port JavaScript is not allowed to access.

Google at least claims to have Chrome tested before unleashing it unto the world. Microsoft apparently does not even test its own products. Trashing mercilessly. I know.

First, IE 8 *overwrites* and *replaces* IE 7. That is as uncool and unacceptable as it gets. You (Microsoft) are replacing a WORKING, STABLE program with a BETA in an all-or-nothing move without too much warning. That’s a load of crap. Suppose you have so much faith in it that you are fine with that.

Next, Security so high it is outrageously stupid. File again, under ‘unacceptable’: on my Windows XP machine, IE 8’s default setting disable JavaScript *ENTIRELY*. I repeat, no f-n JavaScript. Never mind Flash, but you know, it 2008. JavaScript is an unproven, new tool, yup yup. Fail fail fail. Anyway, they tell you that your add-ons are disabled. You click the link to the add-on manager and lo-and-behold, ALL OF THEM APPEAR ENABLED. WTF?

So how do you solve this? According to Microsoft’s support, it is as simple as changing an f-n REGISTRY KEY?! As user friendly as entering a class id to the registry. ARE THEY NUTS? DO THEY EVEN CARE?! Is it possible to goof off even more?! A beta means ‘on the verge of release’. This is plain dreadful, Microsoft. Look in the f-n mirror and like, think again. I am so selling my miserable 10 stocks of yours. You suck beyond belief. Really. Done. Indefensible.

Yay:

• Wicked Fast
• Sorta cute looking
• Search in the address bar works very well
• Design outside of Mozilla’s reach
• Process-based design is interesting, maybe it can actually work, hey think outside the box, yo
• Download manager looks like the Firefox Download Bar extension, only looks waaaaay better
• No Mac version. Please talk to the genius at the genius bar. I am bitter.

Nay:

• No ad blocking. Yeah, Google - the ad people - will let you f- with that. I bet that is like, motivation #1 for this whole adventure
• A remarkably sad day for web developers. Not only are companies going to want to test for another browser like Safari or god have mercy, Opera, you really need another pain in the but in the form of Chrome. And yeah, it renders like Safari, but its JavaScript is all new. Wheee
• No integration yet with del.icio.us and web developer tools that make Firefox sing
• Google needing to support users on Windows. Welcome to hell.
• Only god know which nameless, oh-so-private stats are being collected on us when we use a product from a company that makes money off of that. Yeah, it’s open source, but did you read a million lines lately?
• Facebook not like, 100% with Chrome: The next/previous links in the Facebook image gallery don’t work; the comment on news feed stories do not work; photo tagging is a fail too; the more I try the list gets longer - in short, FB is shafted in Chrome. Petty, I know, but I am sharing. Doubt Facebook, on the Microsoft side and a Google wannabe anti-Christ, wants to care.

Regardless, I root for Google. Another ballsy, way beyond uber-cool idea. Seems to be running. Was a pain to download because apparently they are so deluged with requests it hurt their servers.

How’s this for low-to-lowest brow review?

So how *can* you find that out?
The only way I found out had to do with headers. It appears that when web servers are sent a URL like http://www.enavigo.com/awesome and awesome *is* a directory, the response header will redirect the browser (or requestor for that matter) to the properly specified URL
http://www.enavigo.com/awesome/ which has the trailing slash character. I am sure that has to do with server setup.

Need to research this issue more…

<img src="../images/imageName.jpg" />

This should work in any subdirectory - where ../ means everywhere except the home page: the “../” in the beginning of the src reference tells the browser to go one directory up and then go down to the images directory where the image is stored. On the home page, this should not work, as there is *no directory above* the root directory, where the home page resides.

Still, browsers DO display that image, despite the moronic code (mine!). In other words, when a browser reaches the root directory and a reference is made to a directory above, it will ignore that reference and try to descend to subdirectories under it. I tested this with multiple ../ referencing directories above the root and still, the browsers prevailed.

Therefore, appreciate thy browser (just a bit)… Thank you browser!