This question came in today and I thought it was pretty interesting:

We are building a family of applications (using Coldfusion and Coldbox), all of which run off the same database, for a client. I've also built a chat system (using ColdFusion WebSockets) for one of the apps. So, people logged on to that app can chat with one another.

But we think it would be cool if the chat system could be extended across all the sister apps. That is, a person logged on to any one app could chat with a person logged on to another sister app. Since we define WebSocket channels at the application level, it seems channels cannot span across multiple applications (but that's what we want to achieve).

So, in case you don't quite get it, ColdFusion 10's WebSockets are specific to one application. Given a WebSocket channel named "chat" in application one, if you have one with the same name in application two they won't share messages.

One of the first things I did was recommend Node.js. And no--I wasn't saying to give up ColdFusion. You can easily use Node.js services alongside ColdFusion. If you were to set up a Node.js websocket server on, say, port 8888 then your apps could all make use of it. (I first saw Simeon Bateman demo this.)

But outside of that I suggested using a simple iframe. Dropping in an iframe would let you quickly include your chat application inside of it. I built a quick demo of this. I created two apps (and by apps I mean one page with a dump of the application scope) and then simply added an iframe to the chat app:

This is the index page for an app.

<cfdump var="#application#">

<iframe src="../chat" style="float:right;width:400px;height:400px"></iframe>

The result is pretty much what you expect. As an FYI, my chat demo wasn't really built for an iframe. It could be improved.

So ... there's that. But I was curious about doing something a bit more than chat. What if you wanted the iframe to communicate with the parent window? Turns out that's slightly complex due to browser security issues, but that may not impact you depending on your use case. (For the book on the topic, see Third-Party JavaScript.)

I began with a simple example where all apps were hosted on the same domain:

• foo.com/app1
  
• foo.com/app2
  
• foo.com/chat
  

In that case, your chat app could communicate to the parent rather easily:

if(window.parent.msgHook) window.parent.msgHook(message.data.chat);

Where in app1 I may have:

function msgHook(m) {
  console.log("msghook");
  console.dir(m);
}

I'm not actually doing anything with the message, but you get the idea.

Moving to different domains though gets tricky. Imagine you have these domains:

• x.foo.com
  
• y.foo.com
  
• chat.foo.com
  

If you want X and Y to be able to iframe the chat server and receive messages, you have to use something like postMessage. In compatible browsers, this lets you add event listeners for messages being broadcast from one iframe to a parent (or vice versa).

As an example, I added this bit of code in my app:

window.addEventListener("message", function(e) {
  console.log("msg listener");
	console.dir(e);
});

And then my chat server broadcasted a message using postMessage. Note that I'm using * for the targetOrigin. I can make this more specific to my domains.

window.parent.postMessage({"msg":"foo"},"*"); 

Make sense? I've included all 3 iterations of the app as an attachment to this entry.