Hey folks, we recently had an interesting discussion with some of the folks at Tech Werks about a recent implementation of WebSync On-Demand. The following is a summary from their founder, Bill Baker:

Tech Werks, a video streaming technology company, has been working with Frozen Mountain for several years, integrating Frozen Mountain's WebSync On-Demand services into their video encoders and live presentations. 

In addition to their work with various national and international television networks, Tech Werks supplies video streaming services and specialized on-line applications for the United States State Department. 

Recently, Tech Werks supplied these services for the APEC summits. The most recent Summit (November 2011) was held in Hawaii and involved many world leaders, including Presidents from the US (Barack Obama), China (Hu Jintao), Russia (Dmitry Medvedev), and Japan (Yoshihiko Noda).

During the primary Summit meetings, several world leaders had PowerPoint/KeyNote presentations.

The State Department asked Tech Werks to supply a system whereby each leader could use a simple tablet device (iPads in this case) to display and control their presentation, and send this presentation in real time to 25 other tablets for each leader to view. 

Needing a solution quickly, Tech Werks turned to Frozen Mountain's WebSync On-Demand comet solution as the real-time delivery service. 

Tech Werks integrated Frozen Mountain's WebSync On-Demand SDK into their pre-existing "app", and loaded the app on over 100 tablets, 25 of which were located on each seat in the primary plenary. 

During the summit meeting, each leader had a tablet and could advance forward and backwards through their presentation, and as they did so, all 25 tablets advanced forward and backwards in sync with the presenter.  

The app worked flawlessly, thanks to Frozen Mountain’s WebSync On-Demand Service.

Today I'm pleased to announce the release of WebSync 3.5, which adds full support for Java-based clients, which means we now have native support for Android and Blackberry!

Previously, WebSync was a real-time communications platform for .NET and the browser. With this release, we now have full native support for the full line of most popular smartphones and mobile devices - iPhones, iPads, Android phones, Android tablets, and Blackberry devices too!

We've done our best to keep the APIs between the various languages as consistent as possible, so the learning curve is absolutely minimal.

We've also added (as usual) a few little performance improvements, and in a couple places, better error handling.

So what are you waiting for? Go get the latest copy, or point your script to client.ashx?v=3.5.0!

Hey everyone!

Good news! We've just released WebSync 3.4.2! As always, you can check out the changelog, but the items of note are:

• better support for transferring of in-memory cache between overlapped worker processes, to avoid clients getting inadvertently idled out when the application pool resets and reduce the load on the database for SQL providers
• performance improvements for iOS and JavaScript JSON parsing
• support for changes to the system clock
• performance improvements to the SQL provider
• fix for the notorious IE "c00c023f" error
• fixed memory leak in the JSON parser

So, overall, pretty awesome release, if I do say so myself!

As always, you can grab a new copy of WebSync Server from our downloads page, and for the On-Demand customers, simply point your script to ?v=3.4.2!

We're looking for a new developer to join us in our Raleigh, NC office. Check out the job posting on StackOverflow.

If you're interested, drop us a line at jobs@frozenmountain.com!

It's time for the official announcement :).

WebSync 3.4 is out and ready to rock! A few bug fixes in this release, but the big news is full support for iPhone/iPad/iAnything devices, with the release of...drumroll....the iOS client!

That's right - connect your WebApp to a WinFormsApp to an iPad app to a WinPhone app to an iPhone app to a console app. Whew!

Also in this release, we've also upgraded our documentation a bunch. More code snippets, diagrams, examples, and explanations than ever before. 

We're working on Android support, so that'll be in an upcoming release as well, for those of you who are interested. That'll also include (naturally) full Java client support as well, so we'll be able to add Linux clients to the mix.

Finally, we're working on a slightly new site look, and we're going to start sending out a newsletter as well. The newsletter will include info on new releases, use cases, and maybe some sample code. If you have any ideas of things you'd like to see in the newsletter, we're interested, so please feel free to drop me a line and let me know. Even if that's promoting some hot new product you've built with WebSync :).

So grab a copy of the latest code from our downloads page and get cranking! For those of you using WebSync On-Demand, you can get the latest JavaScript by pointing your script to http://sync3.frozenmountain.com/client.js?v=3.4.1

Happy Coding!

WebSync + Websockets

Fairly regularly, we get the question "what is your plan for WebSync and Websockets"? First, let me clarify - Websockets is a transport over which WebSync will operate, one of many we already support depending on your particular browser and environment. We already support long-polling via xhr, iframe, jsonp...and this will be another mechanism under the hood. However we end up implementing Websockets, WebSync's main API will remain the same - you'll still connect, subscribe, publish, etc.; it'll just take place over a single Websocket connection instead of multiple HTTP requests.

That said, rest assured that we plan to support Websockets in the future. Whether through IIS natively or a custom module remains to be seen (based mostly on whether Microsoft moves forward with an implementation of Websockets for IIS).  To our developers, it should be relatively seamless. If Websockets are available, they'll be used; if not, they won't. Simple as that.

A Spec in Turmoil

We're actively monitoring the development of the spec (we are on the IETF group), but we haven't yet taken the steps to implement it. Why not, you ask? Well...

1. The spec itself is in tremendous turmoil. The various revisions are vastly different from one another, and each browser vendor has implemented a different revision (if they've implemented anything). The group working on the spec (we are in the group, so we count ourselves in this) is taking forever to finalize anything, for both good (lots of valid questions and concerns around security and compatibility) and bad (too much infighting) reasons.
2. Browser support is poor. Safari and Chrome have implementations, but each implements a different version of the spec. Safari is broken - see the next point. Firefox 4 is going to ship with Websockets disabled. IE doesn't support it at all.
3. What *has* been implemented isn't always correct, even for a given vendor. For example, Safari isn't sending the random 8-byte header it should be sending according to the version of the spec it implements, so we couldn't implement it there even if we wanted to.
4. Server support is limited. This point isn't a deal-breaker, but since WebSync already plays so nicely with IIS, it would be nice to see Websockets support come from Microsoft. If MS doesn't step up here, we plan on running with it anyway.

So, at the moment, we're playing the waiting game, and we look forward eagerly to the day when all browsers properly implement a stable version of the protocol.

Comet Lives On!

Another question we often get is "is WebSockets the death of 'comet'", to which I respond with an emphatic "no", for a number of reasons:

1. Old browsers will always be around. People are still using IE6, now 10 years old. Websockets isn't even a final draft form yet, so we'll have 10 years more of supporting older browsers at *least* before Websockets takes over 100%.
2. "Comet" is a concept. Websockets will be included in WebSync when it's out of draft, but WebSync will still be a comet server. The "death of comet" doesn't make sense. Yes, Websockets will mean we can use a better transport for streaming data, but the fallbacks will still be needed to deal with old browsers (see above) and also to handle proxies that don't support Websockets properly.
3. Server implementation is still necessary. Most of the difficulty in implementing a comet server is dealing with the web server and database concurrency, which doesn't change if the client-side implementation changes. You'll still need a way to easily publish and distribute messages to a large number of connections; the only difference is that the connection sticks around for communication in both directions, and new HTTP headers aren't sent.

We can't wait for Websockets to be generally available, but we're also well aware of the fact that it won't negate the need for existing client-side solutions for a long time, nor will it suddenly remove the need for efficient server-side code to manage all those clients.

WebSync On-Demand is back online again. The total outage time was approximately one hour.

At the moment, we believe the outage was caused by a misconfiguration of our load balancers by datacenter personnel. We are attempting to determine how this happened to prevent it in the future.

For those who are interested, for the past 12 months, we've had 6 hours of total downtime, giving us a 99.93% uptime.

Hey folks, we're having a small issue with our server cluster at the moment, and we're working with our data center to resolve the problem. We'll update here as soon as we have things resolved.

[Edit, 12:05EST] The servers are all back up again. Apologies for the inconvenience.

Happy New Year! A new release of WebSync is out! This is basically a patch release, fixing a bunch of minor issues in the 3.3 branch.

Feel free to check out the changelog, download a new trial, update your purchase, or use the latest On-Demand code by pointing your script tag to ?v=3.3.2.

Happy Coding!

Hey everyone, it's that time again!

(Deja vu?)

Well, we had a minor bug in 3.3.0, so hot on it's heels is WebSync 3.3.1. This release resolves a JavaScript client bug that would cause an alert to show up if the following happened in order:

1. you used the meta field in your connect call
2. the server was reset
3. the server-side client record could not be restored (as you'd see in WebSync Express)

For those of you using WebSync Server, and who have downloaded a copy in the past day, you'll want to grab a new copy :).

For those of you using WebSync On-Demand, simply point your client script to ?v=3.3.1

Happy Coding!