Last week I was on the panel at the London Ajax Comet event along with a number of other people representing Comet products. Comet servers are nothing new and there are lots of options out there now, some open source, some free, some commercial, and more recently some as a service.
Some of my blogs relate to Liberator, but I don’t often talk about it directly, explain the different versions or describe what you can do with it.
The video of the London Ajax Comet panel has now been posted along with some slides.. also Dylan has posted some photos he got an audience member to take too.
Here are the links:
Video/Slides: http://skillsmatter.com/podcast/ajax-ria/comet-panel/zx-486
Photos: http://flickriver.com/photos/dylans/sets/72157624493006656/
Now you can see what a bunch of Comet vendor geeks look like!
Thanks again to Dylan and Skillsmatter for hosting the event.
An interesting event last night that I mentioned recently.
Thanks to Dylan for organising the event, and thanks to the other panelists for taking part. It was good to finally meet Alessandro from Lightstreamer, and its good to see the various open projects talking about their technology too. A couple of guys from Nirvana were in the audience and we had a good chat down the pub afterwards.
Everyone on the panel seemed to have similar views on WebSocket, although some have implemented it and some have not.
I’ll post a link to the video and slides when they are available soon.
I have blogged about Why we don’t need HTML5 WebSocket previously – and to recap, it’s not that we don’t need it, it’s not really that important until it is far more widespread and that is a very long way off.
Anyway, Google have just announced that they have Updated WebSocket in Chrome. I follow the hybi mailing list which is where most WebSocket discussion goes on and there is far from a consensus on many aspects of WebSocket, which has led to the changes the Google blog mentions, and there will almost certainly be more. Google noted this too and state that they will continue to update their WebSocket implementation regardless of compatibility issues until a more stable spec is available.
So where does that leave us? The only browser that supports WebSocket is updating and will continue to update its support for WebSocket, breaking compatibility with WebSocket servers, who will most likely also be updating to newer versions as they are available. I think this is the right choice for Chrome and server implementers – but it does mean that WebSocket for any kind of serious web application is clearly not viable. I hope any web apps and server implementations can handle the compatibility issues gracefully so they can fallback to other Comet techniques, as they have to with all other browsers anyway.
I look forward to a day when WebSocket is usable – but for now it’s business as usual.
One of the questions I brought up on a previous blog – Comet servers for a Single-Dealer Platform – was that of bandwidth. The main thing that affects bandwidth that a Comet server has some control over is message size. At the time of that blog I hadn’t looked into this issue with all the servers in much detail, so I decided to dive a little deeper and look at the protocols of some of the Comet servers written about on that blog.
A question that a customer once asked was about message sizes, but the question was wrong, they asked what performance Liberator could handle with 1K messages – they wanted to compare Liberator to another Comet server sending 1K messages. I pointed out that they should let us know what the payload they want to send is and we can see the size of the message in our protocol, and they should do the same with the other Comet server. Maybe we could represent a much bigger payload in a 1K message than the other server could.
I have looked at four servers for this blog – Liberator, Lightstreamer, Adobe LCDS and my-Channels Nirvana. They all take slightly different approaches, but can all be used to achieve similar results. My test case is a single message payload, but I am showing the structure of the messages and will comment on how different payloads may be represented better or worse in the different servers.
(More …)
At the Google I/O developer event a few interesting things have been announced. I blogged earlier this week about Google going real real-time with its Feed API and yesterday they announced some new features in Google App Engine.
The interesting part is this:
Channel API – The Channel API lets you build applications that can push content directly to your user’s browser (aka “Comet”). No more polling for updates!
Google have done things with Comet before, some of which are probably just polling, but others such as Google Wave are fully live updating.
With the feed API and the App Engine Channel API Google are opening up their Comet capabilities to outside developers. I look forward to more details on the Channel API and maybe dissecting how it works. Most Comet solutions implement a number of techniques, mainly for different browsers, so it will be interesting to see what Google have done.
Google have announced a number of other things at this event which I found interesting and look forward to trying out..
There’s a log of talk about the real-time web these days, but most of it is talking about stuff that isn’t really real-time at all. Most of it just means when you access the data it is up to date, or in some cases it means things update for you every few minutes or seconds.
Google’s Feed API gives you access to any public Atom/RSS like data, including lots of Google’s own data. There was a lot of fuss recently about PubSubHubbub and I blogged about how PubSubHubbub is the not quite real-time web.
At Google I/O this week, Google will be announcing some changes to the Feeds API that enable updates to be pushed to browsers. ReadWriteWeb got the scoop on this posting that Google will push real-time feeds to browsers. Not just in terms of details yet, the video shows the code changes are minimal, but what is going on under the covers is what interests me. Is is really real-time? is it polling? Will they pick one, works for all, solution, or try out WebSocket for those that support it. For most things the Feed API will be used for the speed of polling is probably fine, but high frequency polling is just inefficient compared to true streaming. Long polling would sit somewhere between polling and streaming and a good compromise for the client end. What I am interested in is what implementation Google thinks is best for what could be the largest deployment of a web push service yet.
As I mentioned on my previous blog – Comet Servers for a Single-Dealer Platform (SDP) I am performing some new benchmarks for Liberator. These are going to focus on some new things as well as some new figures for our traditional scenarios.
Amongst the new benchmarks will be some tests for publishing from the client, which is key for trading applications, and also benchmarking our container objects. A container is an object that represents a dynamic list of references to other data. Subscribing to the container automatically subscribes the client to its contents. Containers also allow you to subscribe to a subset, allowing efficient display of huge lists. The platform allows containers to be created dynamically based on filter and/or sort criteria too.
(More …)
There is a lot more to a Single-Dealer Platform than just a Comet Server, but it is still a key component and often one of the components bought in rather than developed in house. At Caplin we have dedicated much of our time to building what we believe is the Comet server that offers the best performance and feature set on top for building a SDP. Hopefully this post will explain why we believe this, and where you might have more work to do with the other products.
A Comet server allows an SDP to deliver prices and manage trading between a backend system and a browser client – although many will support other clients too. These days there are a number of choices for a Comet server, and more of them are realising that financial data is a great use case and targeting effort in that direction.
Questions?
If you are choosing a Comet server for an SDP there are a number of questions you should be asking that will have a big impact on the amount of integration and other work you will have to do.
(More …)
I have been blogging on CometDaily since before we started Platformability so thought I would take a look back and see if there was anything there that might be of interest to our Platformability audience.
Early on in CometDaily’s lifetime I wrote a piece on the Evolution of Comet at Caplin which covers how Caplin’s core technology has evolved since the start in 1997. The article was written in 2007, so I thought I would say how things have moved on since then.
The article finishes off talking about Caplin Trader our Ajax trading front end framework. This is still a large focus for Caplin, but we have also expanded out. There is a lot of extra functionality on the backend that was developed along with Caplin Trader – higher level integration to Trading and Permissions for example. Although Caplin Trader allows you to host other RIA technologies within it, we also wanted to more openly support other client side technologies in their own right. So we worked on these APIs to create Caplin Xaqua which is the full stack of our software, from backend integration APIs, through Liberator (and Comet) out to our StreamLink client APIs, which we expanded to include .Net, Silverlight and Flex.
Coming back to Comet, with the new client APIs and also new browsers and browser versions, we improved our coverage of Comet techniques to ensure the best possible connection is made for each scenario.
And the future? Well I have blogged about HTML 5 WebSockets more than once and to reiterate, it is a good new tool for Comet server implementers (rather than people developing web applications themselves) and i’m sure when the market share for browsers supporting WebSocket grows we will be adding the capability to Liberator and Streamlink.
