As always, once you have a new version of a product out, the requests come flooding in. To that end, hot on the heels of our recent 2.4.1 release, we're now releasing WebSync version 2.4.2, fully backwards compatible and ridiculously over-tested!

WebSync Server

For WebSync Server, this release fixes one issue, and introduces some nice new features. Here are the details.

Bugfixes

• We've applied a fix to address issues with encoding of extended characters sets. UTF-8 encoding is now used across the board.

Features

• The javascript client is now more resilient to bad data; as a result, the javascript client will now display a nice message if you attempt to send invalid data through WebSync, letting you know exactly what caused the problem.
• The "Unsubscribe" event will be fired for users that are getting disconnected due to idling, which means all clients are guaranteed to unsubscribe to any channel to which they've subscribed.
• The database name is no longer required to be "WebSync"
• Support for external config files was added
• Connection string names and HTTP Direct Publish settings can now be specified in the config file, allowing you to override attributes you've set in code

WebSync On-Demand

For WebSync On-Demand users, you will also get the benefits of the additional error checking and extended character sets, and will also get a great new feature - meta data! In the past, the one difficulty with using WebSync On-Demand was knowing when users subscribed to or unsubscribed from a given channel. With version 2.4.2, this problem is a thing of the past, as we've added support for meta-information. To take advantage of this feature, you simply add an additional property when subscribing to a channel, "onMetaReceive". This function will receive notifications when new users subscribe or unsubscribe from the specified channel, and you can make your application update accordingly. You can learn more about this new property by reading the subscribe documentation. And for those of you wondering what happens when someone kills their browser without properly unsubscribing first - when WebSync performs its automatic cleanup, you'll be notified that the user has unsubscribed, so you're covered there too!

Don't forget to update your client javascript url to:

http://sync.frozenmountain.com/client.js?v=2.4.2

Those of you using the .Net API, please get a new copy of the WebSync.Core.dll from our downloads section.

With the latest release of WebSync On-Demand comes a new client versioning system. We want you to always have access to the latest copy with the most recent enhancements and fixes, but still allow you to choose when and how you release it into your application.

A typical client script would look something like:

<script src="http://sync.frozenmountain.com/client.js" type="text/javascript"></script>

This will always return the most recent copy of the JavaScript client with the latest fixes.

To target a specific version of the client, simply update the query string to include the version number.

<script src="http://sync.frozenmountain.com/client.js?v=2.4.1" type="text/javascript"></script>

The "v" parameter stands for "version" and can be used to download a specific client version. For production applications, you may want to include the version as a matter of habit. We do our very best to ensure that 100% backwards compatibility is maintained, but integration in browsers can sometimes do interesting things, especially when multiple frameworks/scripts are merged together into the same page. When a newer version arrives, you can then run your application in a test environment with the latest copy to iron out any potential conflicts before pushing it out to your clients.

We're proud to announce that the latest version of WebSync is live in our new premium data center! Along with it comes new JavaScript, .NET, and PHP clients/downloads as well as our brand-new online system for purchasing and managing concurrent On-Demand users across domains.

Every On-Demand account has received at least 10 free concurrent users. If you already had an active domain registered with us, your users have been automatically assigned to your domains for your convenience. Purchasing more users is simple and easy. Just visit www.frozenmountain.com/websync/purchase and enter the number of users you wish to purchase.

Important: to move your environment to the new premium On-Demand center, update your targets to point to sync.frozenmountain.com instead of websync.frozenmountain.com (i.e. http://sync.frozenmountain.com/client.js). No other action should be necessary on your part.

We have incorporated a number of fixes into this release that improve client-side browser support and server-side stability and performance. For the client alone, we ran over 1500 individual unit tests in various browsers to ensure support in as many scenarios as we could envision. We are also now adhering to a stable versioning system (to be discussed in a later post) that should give you the stability of individual releases and us the flexibility to make them available to you on your time.

Please, as always, let us know what you think! Our service is nothing without someone to serve, and we take all comments and feedback with utmost consideration. Thanks for all the great feedback to date - we look forward to making it even better for the next release!

With the new release of WebSync, developing from your local machine (a.k.a. localhost) is easier than ever.

Instead of using special "reserved" keys for localhost, go ahead and use your regular domain key. The rest is taken care of behind-the-scenes.

For the JavaScript client, just specify your domain key. For the .NET and PHP clients/publishers, specify your domain as well (without http://, port numbers, or sub-folders, as usual, e.g. frozenmountain.com).

Update

An option has been added to the Portal which allows you to disable this feature per-domain. Simply uncheck "Allow communication from localhost"."

We are pleased to announce that after many internal revisions and much hard work, version 2.3 of WebSync Server and WebSync On-Demand has been released. The list of changes is extensive. Here are the highlights:

• Server performance has been improved. We have tested over 30,000 actively communicating clients on a single channel on a single server.
• Reorganized and updated documentation. It should be more intuitive to navigate and understand. (No more synchronous/asynchronous tech-speak.)
• .NET and PHP proxy support for pre-processing client requests. Allows custom server-side application logic. Check out the documentation for more details.
• Support for extra data in messages. Authentication and other security features should be easier to implement now if sessions are not available.
• Improved JavaScript support. Browser support is very extensive, going back to earlier revisions further than we can test. Browsers will automatically take advantage of new HTML5 features for improved performance as they become available.
• Enhanced .NET and PHP core downloads. Clients and publishers should see faster communication.

A very big thanks to all the feedback we have received, both positive and negative. You are the most important part of this, and we are always listening to what you have to say.

A Visual Studio plug-in is on the way for WebSync Server customers. Watch for it!

In the past few months, we have been actively developing WebSync, a product and service that will allow developers to synchronize web content securely across multiple browser sessions. Using a technique known as long-polling or "comet", it enables real-time connections among website users.

Part of our plan is to allow the development community to use our server (in beta) as a hosted serviceto let people understand its advantages and prove its usefulness.

The process of developing a drop-in client-side script that would allow remotely-hosted real-time browser synchronization was not a simple one. In particular, cross-site scripting proved most difficult.

For our application, we needed to be able to:

1. Have JavaScript code from the client's domain pass data into JavaScript code on the server's domain.
2. Have JavaScript code from the server's domain pass data into JavaScript code on the client's domain.
3. Have the JavaScript code from the server's domain maintain a client state (i.e. server frame could not be disposed).

If cross-site scripting were not completely restricted, we would be able to:

1. Create an html page on site A.
2. Embed an iframe in that page with a source page from site B.
3. Call JavaScript methods in the B-page from JavaScript code in the A-page and vice versa.

It is my understanding that future web browsers will allow this for domains where the communication is explicitly allowed. However, until such features are present and widespread, we have to resort to other means.

Our solution is to provide a "double-proxy" whereby both domains host a small proxy file that routes data in and out. We rely on the window.name property to pass data, which can be set on an iframe by a parent, and read internally by the iframe content.

The general process is actually quite simple.

Assume there are two pages with embedded JavaScript code that need to talk to each other - page A on site A and page B on site B. Each site also has a special proxy page - proxy A and proxy B respectively.

• Page A creates an iframe whose source is page B.
• Page A creates a temporary hidden iframe whose source is proxy B and whose window name is the serialized data.
• Proxy B reads the data from its window name, deserializes it, and passes it into a JavaScript method on page B.

Here's the catch. In order for proxy B to get a reference to page B, it must search its sibling iframes until it finds a match.

The reverse process is very similar.

• Page B creates a temporary hidden iframe whose source is proxy A, and whose window name is the serialized data.
• Proxy A reads the data from its window name, deserializes it, and passes it into a JavaScript methodon page A.

For proxy A to get a reference to page A, it simply jumps to its grandparent.

There are implementation-specific details (i.e. static/dynamic nature of proxy-invoked functions, deserialization timing, proxy life-cycle/recycling, additional domain verification, etc.), but they detract from the core procedure, and so shall be left to the reader as an exercise ;)

The process is not entirely ideal, as for client applications, it requires the uploading of a proxy/callback file on client servers. It is, however, completely transparent to users, and operates beautifully in modern browsers.