http://stackoverflow.com/questions/9107384/server-scalability-html-5-websockets-vs-comet

What this comes down to is a set of plugins that upgrade IE8 or IE9 to include the new feature through a manual process. So far HTML5 Labs has prototypes for IndexedDB and WebSockets.

It is good to see Microsoft providing this level of support for the upcoming browser technologies. It gives developers a chance to try them out in IE, this is important since the specifications for these features are somewhat unstable it is always good to have multiple implementations to test against to avoid the possibility of relying on a quirk of one implementation. It also shows the Microsoft are not just ignoring these technologies, so gives some hope of them being fully supported at some point in the future.

As 2010 draws to a close it only seems appropriate to write a post rounding up Platformability’s highlights of the year. It’s been a great year and thanks to all the contributors at Caplin we have what is quickly becoming a very valuable technical resource and very popular blog. We’d also like to take this chance to thank all of our readers, especially those of you who have taken time to comment on our posts.

Platformability 2010 Hall of Fame: The Top Ten (Most Read)

1. Jonathan Paul - What does software look like?

2. Martin Tyler – Why we don’t need HTML5 WebSocket

3. Mike Poston – Silverlight 4 – Is it what banks want?

4. Adam Shone – Designing a Kanban board – not as simple as you might think

5. Adam Shone – New Features in Flex 4, Flash Builder 4, Flash Catalyst and Mosaic (part 1)

6. Emin Tatosian - An agile team-board layout that works or us, for now

7. Martin Tyler – Comet Servers for a Single-Dealer Platform

8. Adam Shone -  New Features in Flex 4, Flash Builder 4, Flash Catalyst and Mosaic (part 2)

9. Martin Tyler – Apple releases Safari 5 with HTML5 WebSocket Support

10. Duncan Brown – Narrative Journey Maps

Honourable mentions should also go to two ladies: Tammy Sharpe for such excellent posts as A Singular State of Mind, and Sarah Lawfull, for (amongst many other great posts) Collaborative Culture = Innovative Thinking.

Last, but definitely not least, thank you to Ian Alderson for his 21 detailed posts to Platformability during 2010. Highlights include Agile Software Development – One Size Doesn’t Fit All, and An Estimate is not a Guarantee.

2010 – Top Facts

-20,963 visits, 36, 529 unique page views

-Top 3 Visiting Countries: United Kindom (7,706 visits) United States (3,559 visits) and India (1,127 visits)

-Top search engine used to access Platformability: Google based search

Top referral sites:

-363 visitors referred from Comet Daily

-286 visitors from StumbleUpon

-277 visitors from Twitter

-269 visitors from mattdavey.wordpress.com

-169 visitors from LinkedIn

-91 visitors from singledealerplatforms.wordpress.com

It was a year of…..WebSocket, UX, 2 Minutes, Tech Talks and all things mobile

While 2010 marked a huge expansion in the range of topics the team at Caplin sought to cover, there were some topics that quickly became part of the furniture and began to appear as regular features.

While we wrote extensively about all things HTML5 based, Martin Tyler’s Why We Don’t Need HTML5 Websocket established itself as one of the most read posts on the blog. Throughout the year Martin published several other posts dedicated to WebSocket, making the category one of Platformability’s most popular. Martin had regular comments on his posts containing excellent feedback – we’re glad that people are finding the posts not only interesting, but also informative and helpful. Check out some of Martin’s other WebSocket based posts:

HTML5 WebSocket Failure Rates

Which Version of HTML5 WebSocket?

HTML5 WebSocket Support

Why no WebSocket Server API?

iPhone and iPad WebSocket Support

User Experience in the Spotlight

User Experience (UX) has always been top priority at Caplin and this year our UX team expanded to meet the growing demand for single-dealer platforms with a unique, personalised user experience. For those of you not familiar with UX, take a look at Ian Alderson’s post It’s High Time for Good UX.

The team regularly attended UX events including UX Brighton, and even ran a UX-based workshop at SPA 2010 called Persona Driven Development – Can it Work for you? Take a look at Duncan Brown’s (Head of UX here at Caplin) excellent post SPA 2010 Conference Redux dedicated to the conference and the success of their workshop.

A total of 22 UX based posts were published on Platformability in 2010, showing that UX is a hot topic that we’ll certainly be reading more about as 2011 progresses.

2 Minutes

There are a lot of talented engineers, architects, UX designers and managers here at Caplin, so during 2010 we thought it might be an idea to use Platformability to get to know these people better.

To do this, we ran “2 Minutes” Q&A sessions with a few of the team and were really happy with the results we got. So far, we’ve done 2 minutes with Chief Software Architect Martin Tyler, UX Designer Arthur Smit and Development Manager Steve Morgan. Stay tuned for 2 minutes with Duncan Brown, Head of UX, which will be our first feature in the new year.

Tech Talks

Each week we gather to watch a Google Tech Talk (hosted and run by Jonathan Paul – thanks Jon!) followed by a discussion of the content. The meetings are great food for thought with some really popular follow up blog posts.

Take a look at one of Tammy Sharpe’s most popular posts Know Your Mind, where she reviews David Rock’s Your Brain at Work; strategies for overcoming distraction, regaining focus and working smarter all day long as well as Ian Alderson’s insightful Tech Talk – Behaviour Driven Development – a comment on Dave Astel’s “Beyond Test Driven Development: Behaviour Driven Development.”

All Things Mobile

It seemed like there wasn’t a week in 2010 that went by without at least a few posts dedicated to the rapidly growing world of mobile. From mobile devices themselves to mobile app development, this area is one of our favourite topics and one that Platformability covers widely.

Would anybody want StreamLink for Windows Mobile?

Native vs Web for Mobile

Windows Phone 7 Development

Sencha Touch – mobile web development framework

Optimise for Portable Devices

The list goes on!

2011 and Beyond

2011 is going to be an exciting year for Caplin’s tech blog. We’re currently designing a new look and feel as well as some new functionality that we’ll apply to the blog in early 2011. The newly expanded UX team will be blogging more often, and you can expect to hear more about HTML5, mobile development and more from our team of architects at Caplin. And always, feedback is welcome!

From us to all of our readers, best wishes in 2011.

Adam I and I teamed up and implemented WebSockets within our SL4B and Liberator products respectively. I’m not going to talk about the development of it – hopefully Adam will write something about WebSockets in the browser.

Instead, I’ll write about my initial impression of WebSockets: To avoid accusations of cheating I’d not read the proposal or followed Internet discussions so my first glimpse of the WebSocket specification was at 12:30pm on Monday. These impressions are written in an irreverent way, but as usual with these things, there’ll be a kernel of truth in there if you care to burrow deep enough.

The proposal itself

Over the years, I’ve read and implemented a number of RFC’s so I’m used to the format of them and the clarity that comes with their structure and the language used. With hindsight, I’d say it was a somewhat successful format.

For some reason, the WebSocket proposal decides on an alternate format. Instead of providing a specification of the protocol, it explicitly tells you how to implement it – all 46 steps for the client handshake.

I’m sorry to say that I didn’t follow all the steps specified for a server implementation, which probably means that we’ll fail the undoubtedly forthcoming WebSocket validation scheme. However, implementing it from on the server is fairly trivial, and as a result of writing some tests I’ve had to follow some of client steps as well. When you’re used to dealing with HTTP some aspects of the protocol are a bit odd, which leads us on to…

It looks like HTTP, smells like HTTP, but isn’t HTTP

This really feels like a get-out clause for the hackiness that is the handshake. Given that most production WebSocket servers will also support a HTTP for fallback purposes (see later) it really should be HTTP at the negotiation stage.

The negotiation stage starts by sending what looks like a HTTP/1.1 upgrade request. Except it’s not. Except when it is. The premise for the nonsense negotiation is that it could be confused with a HTTP form post, which is spurious, since from a quick glance it could easily be confused with a HTTP/1.1 upgrade request, which of course it isn’t.

As part of the negotiation stage (and to prove that it’s not HTTP really), an 8 byte body is smuggled to the server. I presume that this is to make sure that everyone has to rewrite all their proxies to support WebSocket, which seems like an excellent strategy for ensuring corporate adoption.

The handshaking algorithm had me chuckling whilst I was implementing it. I’m sure that counting spaces has prevented a lot of accidental MD5 hashing of 3 unrelated pieces of information (as well as not accidentally implementing the almost HTTP1.1 upgrade mechanism which caught on so well that we’ve no need for https.)

There’s nothing like a stable, backwards compatible protocol

Indeed, but it sure isn’t WebSocket! We ended up implementing version 76 since that’s what’s supported by WebKit and hence Chrome and Safari. The current version under construction changes the protocol once more which means that if you written a server you’ll need to update it again – thankfully Chrome auto-updates so on the client side the pain is lessened (unless you try to connect to a server that implements an older protocol version).

A text only socket connection and stop/start bytes

For that retro feel of only being able to deal with text, I’d recommend playing around with a serial cable, either that or use WebSockets. More seriously, being able to tunnel over port 80 is useful for software other web browsers – so why did it take to version 100 and something for binary data to be supported?

No inbuilt connection heartbeats

Badly configured firewalls have a habit of half-closing TCP connections with unpredictable results (both sides may not receive a close notification). Since the point of WebSockets is to create a persistent connection across the internet, bi-directional heartbeats would be a great idea to keep the connection alive. Looking at a later draft, there appears to be capability to do this.

Conclusion

As a result of increased lock down of corporate environments, the ability to create a bi-directional socket connection over port 80 is incredibly useful since it (along with 443) is often the only external port that can be accessed.

However the hybi-76 websocket spec seems to make the widespread adoption of WebSocket almost impossible: One thing that can be relied upon these days is that web proxies interfere with HTTP (or pseudo HTTP) connections, adding on additional headers which will break a strict WebSocket implementation (assuming of course that a client can smuggle those critical 8 handshake bytes in the first place.)

I look forward to the day when a WebSocket specification is produced that is fully compatible with off-the -shelf proxy servers – until then it’s likely to remain a fringe connection strategy not suitable for widespread adoption in locked down environments.

There is lots of talk about compatibility, support and issues with WebSocket which is why most people probably won’t use it directly, but instead use one of the many products or open source projects that wrap up WebSocket and provide some fallback mechanisms for the environments where WebSocket will not work. Since there is an API on the client side it is easy to make these wrapper APIs conform, therefore it is easy to swap it out for other products or remove completely if there is ever a time where WebSocket is ubiquitous.

The problem is, on the server side, there is no API, just a protocol specification.

Existing server side APIs

Years ago there was CGI, a defined interface for writing dynamic content from a web server, this was used by shell scripts, perl scripts, compiled binaries, and these things were fairly portable – at least the portability was in your hands, for example, if you used perl you had to make sure you had perl in your environment. Next came more advanced APIs, Java Servlets, Microsoft’s ISAPI. Servlets, more so than ISAPI maybe, meant you could write Java based server side web applications that could run on any web server or application server that implements the Servlet API.

WebSocket on the server

As simple as WebSocket is to use on the client side, the lack of support for it and therefore the necessary fallback mechanisms prevent it from being usable on it’s own. This leads it to only really being useful within specialist products such as Comet servers which have their own APIs on client and server (Some may expose a WebSocket like API on the client). In these scenarios you haven’t really opened up any new possibilities, Comet servers have been doing this without WebSocket for years, WebSocket just brings a new transport mechanism which in some areas is better, but ultimately the user won’t notice.

Writing a WebSocket application ties you to a particular server side implementation of WebSocket. There is no API to write to other than proprietary ones, and since the whole paradigm of WebSocket (bidirectional communication) does not fit in with traditional web request/response based APIs, such as Servlets, you cannot really write a WebSocket application using existing server APIs. From early discussions on the WebSocket mailing list, it was clear the authors had the goal to make implementing WebSocket so simple that this would not be an issue, as you could just simply implement WebSocket each time you wrote a WebSocket application. To me this seems a bit naive – people have to fit in with existing infrastructure and since WebSocket is not ubiquitous you need fallback mechanisms which are not trivial to implement from scratch each time.

I have been reasonably vocal about how WebSocket isn’t the answer to everything, mainly due to browser support and the time it takes for large companies to upgrade their browsers and operating systems. However, on mobile devices this might not be such an issue and WebSocket could now be a good option for real time web apps on mobile devices. I would still advocate using a product that wraps this up and handles backwards compatibility and browser differences across all desktop and mobile environments.

Developer Days

We have run a similar scheme for the last few years with so called “developer days” where, one or two days a month, engineers are encouraged to take time off their main projects and work on alternate areas of their own devices, much like Google’s oft quoted 20% time. The hackathon however was the first time we had invited everyone to undertake a developer day at the same time. It was also more restricted than usual with the stringent HTML5 theme.

Rules and Prizes

We didn’t want to be too prescriptive with what people worked on, however we did provide a few rules and guidelines:

• The work had to incorporate features that are part of what has generally been coined HTML5 (including CSS3 and such like, even though they aren’t technically part of HTML5)
• Engineers can organise themselves into teams of up to 3
• The use of third party libraries is allowed
• Development must start at 12:00 on Monday, no coding was allowed before this (basically no cheating!)
• Pizza would be ordered for 20:00 to ensure that anyone still working then had enough sustenance
• The winning entry must represent something that can genuinely be added into our products, however there would be a runners up spot for the most innovative use of HTML5, which didn’t necessarily need to fit immediately into a product
• From 14:00 on Tuesday each of the team would have 10 minutes to present what they have developed to the whole company
• Three judges (our CEO, CTO and CCO) would be responsible for determining the winning entry and the runners up

To spice up the competition, there were prizes lined up for the winning team and runners up, plus an even bigger incentive (in my opinion) that the winning feature will be added to our product set. Other features may be included in the product at the discretion of the management team.

The Result

I’m glad to say that the majority of the engineering team participated in the event, with a very high standard of output. Unfortunately we’ll only find out later today who won, but, at the risk of sounding like a cheesy Hollywood movie script, in my opinion everyone involved was a winner. <groan/>