We've been hard at work on one of the most requested features for Wildfire, HTTP Binding. This feature will allow clients to connect and communicate with Wildfire over HTTP, including AJAX web clients. There are several popular clients out there already utilizing the HTTP binding protocol, such as JWChat. All of these clients will benefit as they'll be able to connect to Wildfire without any extra configuration or external components as were needed before.
Performance
One of the things we've focused on in developing this feature is performance. With AJAX growing ever more popular, HTTP performance has become a huge concern for server administrators. Traditionally, HTTP servers are optimized for large numbers of short-lived requests (people clicking from web page to web page). AJAX breaks that model since web connections are held open for long periods of time. This problem directly applies to HTTP Binding since virtually all web IM client implementations use AJAX. To help improve the performance of the HTTP Binding component, we've upgraded our embedded Jetty server to its latest version, 6.0, which includes support for Java NIO ("New I/O") and continuations.
One of the main benefits of NIO is that you can have a small pool of threads handling I/O operations instead of one thread per a socket, which allows much greater scalability for large numbers of client connections. Jetty 6 also includes a continuations feature which further optimizes thread handling in the server. The standard Ajax programming model is to connect to the server and then wait until data is ready (such as a new IM message). Continuations allow the server to free up internal resources while the client is waiting. These two optimizations should allow Wildfire to handle a huge number of HTTP clients (significantly more than any other HTTP Binding implementation). We're just starting performance testing now, so stay tuned for actual numbers. We also added HTTP Binding support to connection managers, which provides furthers performance and scalability options.
Ease of Use
Like any other Wildfire feature we wanted HTTP Binding to be easy to use. The configuration of the feature is automatic -- no patching and no external components are necessary to get it up and running. The server administrator can configure the ports that is runs on and also various other settings such as how often clients can forward requests to Wildfire and how long to wait before Wildfire will consider a session inactive and invalidate it.
What's Next
The HTTP Binding feature is only one part of the equation, as it just provides the building blocks for XMPP web clients. But we're also working on direct web client support and will have more to announce soon, along with a timeframe for when HTTP Binding will make it into an official Wildfire release.
Comments
This post has 7 comments. We encourage you to please post your own!
michael
Oct 27, 2006 at 2:04:13 AM
Your next major feature should be the ability to have multiple xmpp domains setup. So people that run more than one web site can create more than one xmpp extension (john@siteone.com, john@sitetwo.com - for example). This is the only thing holding me back from recommending wildfire to my company.
David Snopek
Oct 27, 2006 at 4:39:05 AM
I was about to start the process of porting the JabberHTTPBind0.4.war servlet to a Wildfire plugin, so when I saw this news, I immediately grabbed the Wildfire SVN to look at the code. But I can\'t seem to find it. Could you point me to where development of this is taking place? Thank you!
matt
Oct 27, 2006 at 4:54:12 AM
Michael -- definitely a feature we've been considering. There's always more to do!
Tim
Oct 27, 2006 at 7:10:24 PM
I believe it has the best performance on all the http binding modules available.
I would like to see the feature of session key support (XEP-0124: 13. Protecting Insecure Sessions), it can increase the security level and is easy to implement on server side.
wroot
Oct 27, 2006 at 10:02:27 PM
Maybe the "direct web client support" could be an EIM feature? Leave something for your buisness
alex
Nov 9, 2006 at 3:34:30 PM
Tim,
There are a couple sections of the XEP we are still missing. They will be implemented before the final release of Wildfire 3.2, including protecting insecure sessions.
Paul Sherwood
Dec 6, 2006 at 4:28:28 AM
Ajax will be greatly recievd!
Multiple domains, I agree, a defo need.
jid and email addresses should be the same or at least one should be able to use email addresses for jid, without the need to try adding escape codes etc, even using escaped characters it is all a bit ropey. Email address are globally unique, so why not use them? They also fit well into a multiple domain model.
Better API to programatically administer/interact with Wildefire remotely(sounds like 3.2 may well be going some way to addressing this though), we already have all our users in SQL DB's not much point in duplicating.
Better documentation and howto's. Custom database instruction is quite poor.
And for my application specifically I would like to be able to change presence and rosters centrally, 'severside' .
Dont get me wrong I really like Wildfire, I think Jivesoftware have done an awesome job, I have built an interactive CallManagement system based on it, I want these to be constructive points, not disgruntled, axe to grind critism.
Paul