Platformability

Latest Updates: Browsers RSS

• 

  Google going real real-time

  Martin Tyler 9:34 am on 18th May, 2010 | 0 Permalink | Reply
  Tags: Browsers, Comet (23), Real-time web (23), WebSocket (9)

  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.
   

  Reply Click here to cancel reply.

  Name (required)

  Email (required)

  Web Site

   
• 

  Evolution of Comet at Caplin

  Martin Tyler 12:45 pm on 16th April, 2010 | 0 Permalink | Reply
  Tags: ajax (13), Browsers, Comet (23), WebSocket (9)

  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.
   
• 

  Interesting stuff coming out of MIX10

  Patrick Myles 11:55 am on 17th March, 2010 | 0 Permalink | Reply
  Tags: ajax (13), Browsers, IE6 (3), Microsoft (5), Silverlight (6)

  Microsoft’s MIX10 Developers and Designers conference is currently running in Las Vegas. Sadly I’m not attending as it sounds like lots of fun…

  There has been lots of buzz and some really interesting bits coming out so far including Silverlight 4 RC, Internet Explorer 9 preview (with HTML5 and CSS3 etc.), Windows phone information, etc.

  Scott Hanselman has posted a great roundup of the announcements and keynotes.
   
• 

  The banking exodus from IE6 begins?

  Patrick Myles 5:22 pm on 2nd March, 2010 | 1 Permalink | Reply
  Tags: ajax (13), Browsers, IE6 (3), JavaScript (8), Microsoft (5)

  We’ve all seen the retail and consumer space push to ditch IE6 gathering pace over the last 6 months, including a petition to the UK government and Google’s announcement that their online productivity suite stopped supporting IE6 yesterday. But the corporates (and specifically banking)  have been a lot more reluctant to follow suit. But is this about to change?

  Rumour on the street has it that, finally, the investment banks are going to start abandoning IE6. Barclays are allegedly going to do an enterprise-wide rollout of IE8 in Q2 of this year (put back from Q3 last year). Even more surprising (and impressive) is a rumour that Standard Bank of South Africa are going to ditch Microsoft browsers completely and move to Chrome for their corporate standard!
   
• 

  Supporting IE6 - a poison chalice or the holy grail?

  Patrick Myles 10:43 am on 14th July, 2009 | 6 Permalink | Reply
  Tags: ajax (13), Browsers, IE6 (3), JavaScript (8), performance

  One of the big benefits of Caplin’s browser-based SDP platform, Caplin Trader, is that it can run in virtually any browser without the need for plugins or special configuration.

  This is no mean feat for a complex, high performance, low latency trading portal framework written in JavaScript and running to >250KLOC. Although IE8, Firefox, Safari and Chrome are similar enough to make it relatively straightforward to support each of them, IE7 and, particularly, IE6 are a different story. They are riddled with quirks and bugs in their layout, rendering and memory management engines. In addition, developer tool support is starting to lag. Worst of all, their performance is diabolical compared with the recent crop of competitors.

  However, IE6 is often one of our customers’ main target browsers by default. Sadly the big financial institutions, and to a lesser degree their clients, run with locked-down and often out-of-date desktop components. This limits their capacity to upgrade or install new browsers, though it’s true that some of the smaller firms are able to do so more easily.

  So, should we continue to support IE6? How should we encourage our customers and users to move to newer browsers? What are the benefits of doing so?

  (More …)