Warning: technical content ahead!

Recently, we were recently doing some work for a client when we came across a minor problem. We were building an application that had a bit of a unique requirement: the entire application had to work with the inclusion of a single <script> tag. Scripts could be added dynamically, but the end user had to only see a single tag.

"Simple enough", we thought; we'll simply combine the JS and CSS server-side, and be done with it. Of course, that would have meant manually extracting the JavaScript for the WebSync client from the server code. Now, that's not difficult to do (it's just an embedded resource), but we were curious if there was an even simpler solution. An extra request was completely acceptable, and since we were already using jQuery, we figured we'd just use that to load the script. The result was this:

$(function(){
  $.getScript("/client.ashx", function(){
    client.initialize();
    client.connect();
    // ...etc
  });
});

"Great", we thought. Problem solved. But then we realized that none of our client requests were being sent anymore! We pondered for a moment, and then remembered that the WebSync client is designed to monitor the "contentReady" event of the DOM so as to avoid the dreaded never-ending loading indicator. So, if the client script loads after the DOM event has already fired, the client is never notified that it is allowed to start making requests.

Thankfully, the designers of WebSync (that's us!) put some thought into this problem, and had a solution already waiting in the wings:

$(function(){
  $.getScript("/client.ashx", function(){
    fm.utilities.ready();
  });
});

That handy extra line tells the WebSync client that the DOM is ready to be used. It then fires any events that were queued up in the addOnLoad() utility function, running them immediately. That's it! So what're you waiting for - get coding!

Well, it's been awhile since we've written anything here, so I figured it was about time to get some more news out. We've been hunkered down working hard on the next revision of WebSync, which is coming soon (don't worry, I'll post about it here so you'll get all the juicy details). In the meantime, however, I thought I'd write down a couple of interesting things that have come up in the past month or so.

The Most Difficult Thing™

Writing a comet server is hard. I don't think anyone would deny that. Implementing a solution that scales vertically, horizontally, is robust and is easy to troubleshoot is no walk in the park. But the real question is: is that the most difficult thing we've had to do?

Well, the answer is probably yes ;). But, there's a *very* close second. And that is creating an API that's simple to use, but also powerful enough to handle all the corner cases that developers want to use it for.

That's been a major focus for us with our upcoming version of WebSync: a clean, easily understood API that anyone can use, but that also can be twisted and manipulated in crazy ways so developers who are pushing WebSync to the max can still do what they want/need with it.

A Rose by Any Other Name

Although Shakespeare's claim that it might smell as sweet might be true, if you called a Rose a Skunkweed, there might be fewer people who would try to smell it. The same principle applies to APIs - if you don't use a name or convention that makes logical sense when naming your methods, properties and events, there will be few people who would try to use it, making the API difficult to use

Not only does a poor API make your software difficult to use, it makes development with it frustrating, which is a terrible thing indeed; nothing will turn developers off your software faster than being given stupid choices that have no obvious distinction. Our goal for the new version of WebSync? Make the software so easy to use that you don't need documentation. (Don't worry - we ramped up the quality of our documentation too, so you can use it, you just are less like to need to do so.) We had many...ahem...vociferous dicussions...about how to name our API to make it the absolute best API around, not just for a comet server, but for any software component available.

The end result is hopefully an API that's so clean and simple to understand, that even if your intellisense breaks, you'll know exactly what calls to make and arguments to use when implementing your awesome solution with WebSync. And if you find the API has problems or is confusing in places - we want to know! You'll find all our contact info here.

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!