Web-hosted IM applications: a re-introduction
People keep asking how SamePlace's web-hosted IM applications actually work, out of curiosity as well as interest in developing something, and indeed, apart from early texts on the old wiki, I've written precious little about the technical side.
It's time for a re-introduction. But before that, to give you an idea about why they exist, consider a simple question. If you were to program a blog engine, or a wiki, or an auction site, or ..., how would you distribute it to your users?
- as a web site;
- as a Firefox or IE or Safari update.
The question may sound rhetorical. Believe it or not, in the field of Instant Messaging the second choice is still the norm.
IM Applications
You're chatting with someone over IM. XMPP being the wonderful protocol that it is, it doesn't assume that you're only going to bounce plain text back and forth. No, it wraps it all nicely in XML. Simple chatting looks like this:
<message from="ford@betelgeuse.org/SamePlace"
to="marvin@space.org/SpaceShip">
<body>What's up?</body>
</message>
<message from="marvin@space.org/SpaceShip"
to="ford@betelgeuse.org/SamePlace">
<body>I don't know, I've never been there.</body>
</message>
Since it's XML, a message can happily carry an application-specific payload, identified by an xmlns (namespace) attribute. Say that during your chat you both are also browsing a synchronized map:
<message from="ford@betelgeuse.org/SamePlace" to="marvin@space.org/SpaceShip"> <panTo lat="41.13" lng="14.78" xmlns="MyMapApp"/> </message>
With that, Ford's side of the app is telling Marvin's side of the app, “hey, display latitude 41.13, longitude 14.78 over there too!”.
Connectivity vs. functionality
This is all well and nice. But why, you object, with such a flexible protocol, so little beyond “chat” has crept inside our everyday use?
Because of development model. Developing and distributing such a map application would require:
- client writers to agree on what the app should do;
- client writers to agree on a protocol for their implementations of the app to communicate;
- client writers to implement the app and upgrade the client;
- users to download and install the upgraded client;
- getting most of this right the first time, since iterating in such a scenario won't be easy nor fun.
Compare with how so much smoother things run in web development land:
- app developers write the app and publish it to a server;
- users all get the same version of the same app;
- client (browser) developers don't need to do anything.
This is the model I tried to make available with SamePlace/xmpp4moz.
The missing link
The browser acts as a container for remote functionality. It lets you talk to the web app and mostly stays out of your way.
Back in the summer of 2006, while writing a simple collaborative note-taking app for SamePlace, I wondered whether a similar “container” approach would work. SamePlace was part of the browser already, so it just had to act as a broker between two web-hosted IM applications (one loaded by you, one by your contact). Well, it didn't take long to verify the core idea, and the feature was available as early as the first xmpp4moz public release in October 2006.
The client side provides connectivity with your contacts. When you want to interact with someone on an IM app, you invite him or her over, and from then on the app shares your IM link. The app is a web page, so everyone is always up to date and all the instances are automatically interoperable.
'nuff talking. How does the code look like?
From the app developer's point of view, it goes more or less like this:
var ns_app = 'MyMapApp';
function onLoad() {
xmpp.init();
xmpp.on(xmpp.event('message'), function(message) {
if(message.ns_app::panTo != undefined) {
var latitude = message.ns_app::panTo.@lat;
var longitude = message.ns_app::panTo.@lng;
map.panTo(latitude, longitude);
}
});
}
The above will catch incoming messages with the “MyMapApp” namespace and react, causing the local map to pan to the given coordinates.
You can see a working map application here and its commented JavaScript source here. It's about 60 lines of code and pretty digestible. To play with it, right-click on a contact and select “Interact → Misc → MapSync”. Or for a demo of a chessboard and a drawing board, watch the videos in this post.
Closing words
I hope I covered the important stuff. If I left you hanging about something, peruse the comment form or the mailing list.
More web-hosted IM apps are one of the ideas in our Summer of Code 2008 application, so if you're a student and you're curious about them, check that out.
The magic of xmpp.init()
Hi,
I have been looking at the code for MapSync, and I understand everything except the line of
xmpp.init()
Well, I understand that it "initializes" the XMPP object for you, but I am unsure what it really does, how this interacts with SamePlace, etc'. Could you describe a bit more from the SamePlace architecture point of view how it does this?
My intuition says that this 'xmpp' object knows who to send the messages to, which is why xmpp.send() does not need a "to" field in the XML or as an argument. Is this the case? If so, how hard would it be to create a MUC version of this, such that multiple people could share an application at once?
There's very little magic there. :-)
There's very little magic there. :-) Check out http://apps.sameplace.cc/mapsync/xmpp.js. The 'xmpp' object is a convenience wrapper around the chrome/content communication mechanism.
My intuition says that this 'xmpp' object knows who to send the messages to, which is why xmpp.send() does not need a "to" field in the XML or as an argument.
Messages are really sent like that, without a 'to' field, since the local part (xmpp4moz) already knows who you're sharing the application with and fills the recipient in for you. (It's also a security measure.)
If so, how hard would it be to create a MUC version of this, such that multiple people could share an application at once?
Carefully written applications will already work in both 1-1 and MUC settings. This is the case, for example, with the chat app of SamePlace itself.
nifty...
Yeah, that's nifty. A couple of follow up questions:
1. Is there a real/measurable performance hit for this type of chrome-content communication? I am guessing it is fine for most apps, but maybe a real-time game or some data sharing might be problematic if there is.
2. So for the MUC scenario, it seems that as long as you didn't do anything too horrible, you could just subscribe to the chat messages, and update things on your application based on that. You point to the SamePlace chat app - is there any code to look at?
3. So with this mechanism of using the hidden div, can you share the same web-app with multiple people (by this, I mean have N different maps open, one for each user)? It would seem that it would clash in a way, because it is SamePlace/xmpp4moz that is keeping the "to" state.
I find xmpp4moz/SamePlace fascinating, but I know very little about Firefox development, and I always found the xmpp4moz dev docs a bit haphazard in order to delve in.
1. Is there a
1. Is there a real/measurable performance hit for this type of chrome-content communication? I am guessing it is fine for most apps, but maybe a real-time game or some data sharing might be problematic if there is.
My guess is that we'll eventually encounter such a hit, because DOM mutation events in general aren't cheap. At that point we'll move from DIVs to a global page object to reduce steps between posting messages and actually delivering them. (This is also a good reason to use the wrapper 'xmpp' object rather than the DIVs themselves -- future proofing.)
2. So for the MUC scenario, it seems that as long as you didn't do anything too horrible, you could just subscribe to the chat messages, and update things on your application based on that. You point to the SamePlace chat app - is there any code to look at?
Sure! It's here.
3. So with this mechanism of using the hidden div, can you share the same web-app with multiple people (by this, I mean have N different maps open, one for each user)? It would seem that it would clash in a way, because it is SamePlace/xmpp4moz that is keeping the "to" state.
State is kept per-browser-tab, so you can have many instances of the same app talking to different users, many instances of different apps talking to the same user, and even many instances of the same app talking to the same user (though that doesn't sound particularly useful :-)), with no clashes.
I find xmpp4moz/SamePlace fascinating, but I know very little about Firefox development, and I always found the xmpp4moz dev docs a bit haphazard in order to delve in.
Yeah, that's partly my fault -- too much coding, too little communicating -- and partly a bootstrapping problem -- it's hard to produce good docs without other developers asking questions, and it's hard for people to develop without good docs. Hopefully we're tackling this, one bit at a time. (There's even a SoC idea about it, possibly the most unusual of them all.)
on a similar note, i notice
on a similar note, i notice most all of the examples use /SamePlace. Does the xmpp library require the sameplace server to act as a mediator? can i use any jabber server?
Sure you can!
Sure you can! The SamePlace account wizard even has presets for GTalk/GMail. The resource part of the JID (the thing after "/") is arbitrary and traditionally signifies the place you're connecting from (home, office, ...) or the client you're connecting with; it has no relationship with the server you're connecting to.
Since I use SamePlace as client (unsurprisingly ;-)) I tend to put that as a resource without too much thinking.