About Martin Tyler I am Chief Software Architect at Caplin. I've been here basically from the start, nearly 13 years ago. I designed and developed the core of Caplin's technology stack, including Liberator and have worked on nearly all of Caplin's products in some capacity.
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.
On July 13th I will be at The Skills Matter eXchange on the Comet Panel for the London Ajax User Group. Details can be found here: http://www.meetup.com/londonajax/calendar/13682478/. Sign up and come along if you are interested.
It should be an interesting event, with representatives from a number of Comet servers on the panel: APE, cometD-Jetty, DWR, Lightstreamer, WebSync, Meteor Server and of course Liberator..
A Google Moderator page has been setup if you want to add a question for the panel.
The iPhone 4 announcement obviously trumped this at WWDC 2010, but Apple have also released Safari 5. If you read about what’s new you will see lots of HTML5 stuff, including WebSocket.
But as I wrote about last week, which version of HTML WebSocket? Is it the same as the latest version of Google Chrome? Google made a clear statement about the version and how it will not maintain compatibility until the specification is more stable, but I cannot find any info from Apple on this. Is it the same code base since they are both WebKit browsers?
So that’s the two smaller browsers (market share) with some support for WebSocket, when will IE and Firefox join the party?
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 …)
