Sure. I think there are more people using HTML 5 than we are aware of and particularly the iPhone users. There are things in the new Safari browser on the iPhone platform like the HTML 5 storage, application caching, these are all new features that are coming into play now. There has been a large announcement from the Mozilla community, Dion Almaer he recently announced Bespin which is built on top of the HTML 5 platform as well, uses the canvas tag in order to do rendering in browser and that is a new capability coming to browsers that's really challenging what Flash technologies and Silverlight are doing today with the plug-in.
2. So you are optimistic about HTML 5 implementation in browsers? You mentioned Safari 4.
Safari 4 has a lot of new features, they are not alone, I think it was actually Opera who was actually pushing the envelope for HTML 5 initially, they were the initial group to push service in events. Post message is another HTML 5 implementation that has pretty much been adopted by all the browser platforms, including IE8 surprisingly who is usually not at the forefront at this kind of emerging technologies.
I think that they would definitely challenge the commodity space these plug-ins are in today which is generally around media streaming, but like every technology they will progress and move into other areas, and create a richer web. But that means that those baseline features will be more accessible and be a more democratizing technology since they will be available in the open web platform.
Sure. This is effectively a socket API for JavaScript developers, it enables them to open up a TCP connection, directly to any backend service that they choose, which means that the browser is now capable of being a full flat client to any service in much the same way that we saw with client server architecture, so that means that you get the nicety of deployment for the web but you get the feature set that you would get in any Rich Internet Application that has full duplex communication back to a specific service. So imagine having full fledged XMPP client capabilities in the browser or JMS.
5. Could you also elaborate on server side events? What are the differences with Web Sockets?
So, server side events is unidirectional, so it's push up stream to the browser and this is really a standardization of Comet. There has been a lot of work in the Comet community about how to create push or http streaming transports and all of the work that has been taken from that has been formalized into the server side events standard into a very simplified API, that hopefully would get wide spread browser support. You already see an implementation in Firefox's trunk, so we should be seeing that in the next release candidates and then Opera has long support for server events.
The big difference is the ability to move away from polling. When you are dealing with Ajax technologies if you want some real time interaction or simulation thereof with your server environment, you are constantly having to poll the server for information. Comet in order to actually be a scalable mechanism for doing this uses a longer poll. Something that we call "the long poll" where you have a long standing connection when the server sends some kind of event that connection is severed and then the client is forced to reconnect. Both these introduce an abundance of network traffic as you are sending a lot of http headers over that network and then you are also pegged to a specific ... on that poll. In the case of Web Sockets you have an open connection that is bi-directional and I should clarify that this is single connection as opposed to what you would have to do to simulate bidirectional communication in either Ajax or Comet, so over this single socket connection you are just streaming. There is never a reconnect there is always a long standing connection.
Sure, Web chat is a great example. There are a lot of Ajax based web chats out there and they typically have to poll, so what you will see is a slight delay in the message being delivered to the various clients who were connected to the server. You would also see a higher network traffic in the case of common implementations you would see an improvement but you would also still see the latency delays and you will also see some scalability issues since you are generally dealing with a long poll doing too many long polls on high message interactions, usually calls some kind of context switching on the server. In the case of Web Sockets you wouldn't have to do that context switching because you are not closing and reopening that connection and then the traffic is also much lower because you only send one http request.
I think it's actually a combination of Web Sockets and the other features in HTML 5 but you will see a migration of applications into the browser so there is more logic how is in the browser and we see a thinning of middleware, middleware becomes more a place for data consistency rather than having to handle your business logics in that one centralized area. That also makes better use of underutilized CPU usage. Most client desktops are running Word applications or Excel, nothing more, so they are wide open for bandwidth and had plenty of memory usage so pushing applications out that far is not out of the question. You also see more efficiency in having a fully packaged application you can actually have that live at the edge of the network with the CDN for instance, so you have efficient delivery and download of that application as a complete package.
I can give you a rough example of deployment. Many of our customers and prospective customers are actually in the financial space, and they are rather reluctant to disclose who they are. However there is one user who is using our open source product and they built a chess game around it, it's called "Chessvegas.com" and it is actually based in Russia, but they are actually using our API's to talk to active MQ so basically the entire game is built around GMS messaging to the web.
Yes, there is one other effort that I know of that is attempting to do this. Last time I checked they were actually behind, they were implementing TCP connections which was the first iteration of Web Socket. TCP connection was actually defined as a way of allowing somebody to remote their train from a web browser, actually have control of that train. But since then, haven't really checked back with that project, but it may have progressed to Web Socket but I don't think it has the same set of features that we provide. In terms of whether JavaScript API should provide some kind of emulation there, since we have an open source product I hope that they wouldn't and they would just take whatever we have and use it in their product, but if they were competing that would be great. I think that it would help evangelize the standard. I would love to see something from Mozilla put out, especially with all the work that has been done around HTML 5 within that particular foundation.
11. How do you implement that JavaScript compatibility layer exactly?
The secret sauce for this is basically we check the browser environment for three plug-ins and that is the Java plug-in, the Flash plug-in and Silverlight plug-in. Usually we default to the Flash plug-in because it's the most common but it's through that plug-in that we proxy a single socket connection so that we can allow or facilitate the Web Socket API. If none of those are involved then we fall back to a common transport, but what's unique about that particular scenario is that the upstream communication is based on server side events. So, the worst case scenario is you are running the latest version of Firefox that has server side events native, and that is your upstream communication so it's an optimized common transport, if you will.
XMPP is actually available now, that is a fabulous example of a very interactive and rich protocol because there are things such as presence which is something that everybody is trying to extend on the web today whether it's collaboration, whether it's my friends online, what have you. Another good one is AMQP which is an open protocol for messaging that has been pretty strong in the financial community. It has actually been adopted by JBoss messaging, so I would imagine that that particular protocol would see much interaction being a very strong protocol just within the messaging venue and possible messaging on the web via Web Sockets.
13. Are there any cases or protocols that you feel would be wise to avoid building with Web Sockets?
I think that there is some fun protocols that you can do like Telnet, but the usefulness of it is probably very limited. Things of that nature should probably be avoided unless you just want to learn the protocol for fun.
In a uniform world that wouldn't happen I can't guarantee it won't happen again. I don't really have an answer as to how you can change that, there are a lot of groups out there advocating for consistency but it doesn't seem like the vendors listen, I think some are more receptive than others, and I think there are some particular browser vendors that we can call out, that have been offenders of avoiding the spec or trying to create or massage their own spec. I have my doubts. I think that is sadly one of the reasons why an emulation layer or a layer of abstraction that creates some kind of consistency will probably remain even when most browsers finally will implement HTML 5.
Actually Douglas Crawford made an interesting blog post not too long ago and he suggested that there should be an HTML 4.2 rather than an HTML 5. And he felt that there should be a smaller iteration rather than this large iteration that HTML 5 is trying to attempt. I think that looking at the best of breeds of things that are coming out is a very good approach in terms of figuring out what the industry needs when you are trying to formalize a specification. The danger is pulling in things that are more experimental than useful, so it's yet to be seen because there is a lot of questioning as to what the uptake of things like SQLite or app caching is actually going to be. Most likely those are probably core features and will remain but there is a little bit of skepticism and that is what makes HTML 5 kind of unique because unlike most specs where you are basing things off of tried and true industry practices, there is a bit of experimentation in it which is both unique and somehow dangerous.
The iPhone is probably the best example for this. Particularly, Safari, which is probably the most advanced browser I could say right now for HTML 5, I could be wrong on that. But they are pretty prominent in terms of the features that they support. And particularly if you look at the application APIs for web for iPhone, those use cases are very much of what we hope to see in the future of having apps download from a server, having them cache within the browser, and then have them functioning within the browser based on offline resources or through socket connections. Which is really taking the desktop and moving it into that browser environment and having all these significant features that we would want minus desktop access which can easily be bridged.
I would say there is probably the first incarnation, there is probably going to be frameworks that make things easier, provide more services that would ride on top of that, but it provides the root capabilities things like socket connections, things like storage in the browser and I hope it doesn't annihilate it entirely because I like my Mac.
The basis of that application is still JavaScript and HTML so it's still within the same box, the browser. The hackery that can go on is still limited to cross site scripting, things that could possibly happen to you on the web today. But outside of that the security considerations haven't changed greatly.
The date is 2022 last time I checked which is too long to wait. But fortunately browsers are moving very quick to support these features and open source projects like Kaazing provide emulation layers so that you can actually use these in browsers that don't support HTML 5 at all.
I think it will accelerate that trend, actually I think that trend started with plug-in technologies. We see like if you look at the Adobe stack you have a Flash plug-in talking to what's called a LifeCycle Data Services and that is really data management to client, there is no application server tier in the middle of that. You can play with things like Blaze DS to bring in some kind of state, but in general you see a thinning at that point. I think that you'll see a similar model with HTML 5 only it will be widely adopted, since it's built on democratizing open web platforms, but I think we are at a tipping point where you need more people willing to make that jump because we are very comfortable in this application server environment at this point. But over time there will be a thinning of the application server and more services will find their way on to the web and there will be less date found in the app server.
I think that we will see the same emergence that we saw with Ajax. When Ajax first came out it wasn't terribly reliable, you had to do various hacks across platforms and then there were things like Dojo and prototype that actually made it accessible and made it reliable, so HTML 5 will probably lend, will probably be a variety of implementations of it and there will be frameworks around that that would help application developers get around the nuances of each individual browser.
Predicting the future is always a dangerous thing to do. It's kind of interesting because I actually prior to being involved with HTML 5 I was involved in ... which is completely different from this HTML 5 concept where you have dumb representations on the server. But what you find is that by doing that scalability is limited because you are carrying so much state and when you are trying to cluster that out, things get a little bit difficult. HTML 5 represents a drastic departure from that, so I think it's going to push a lot of comfort levels for some time before you see a massive adoption on this particular technology, especially when you deal with certain verticals within the development community like Java development which is considered server side pushes much state logic into the server as you can. So trying to bridge the comfort level to reach HTML 5 will be difficult for some time. People within the Ajax community are a little bit more open to pushing much as they can into the client, if not all of it maybe could be a little bit risky at this time. It's really how do you get all these different ideologies and fold them into one. Which I haven't seen done in the past decade of development. I think there will be variations there for some time.
It provides some tools to provide that cinematic style that user interfaces that Flash, and JavaFX and Silvelight can provide. However, is how those tools are welded that would determine the interface. It's more of a question of design practices in the end than the technologies themselves. But the capabilities are there to, or will be there, to build the same kind of rich cinematic user interfaces that we see with the plug-in technologies, I think Bespin is a very good example of those capabilities.