Hey everyone!

We have a new release of WebSync, version 3.2. This is an awesome release, as it adds a bunch of new features and gives a dramatic boost in performance.

Here's the quick summary; for a detailed list, check out the changelog.

• Improved connection management in the .NET client, including enforced timeouts to ensure connections are destroyed no matter what after a specified period of time
• Shutdown management so WebSync shuts down quickly and gracefully when reset
• Improved error handling on initial load, including detection of invalid method signatures for event handlers
• Improved Azure support via the stateless SQL provider
• Improved documentation to work via the file system in IE
• Huge performance improvement with respect to message throughput

The biggest change is the performance improvement. Previously, WebSync was able to deliver upwards of 30,000 messages a second. With WebSync 3.2, it's now capable of delivering over 100,000 messages per second!

As always, for those of you using On-Demand, simply adjust your client script to point to client.js?v=3.2.0, and you'll get all the latest changes. For those of you using WebSync Server, check out the Portal and download the latest copy from your Order History.

Happy coding!

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 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!

Hey everyone!

Minor point release today, but it does have a pretty important fix for the JavaScript client in Internet Explorer when the connection has a "soft" reset (like changing your web.config).

Please update to 3.1.0.1 if you're running WebSync 3.1! (You can check by right clicking on your file an selecting "Properties")

Customers: You can grab a copy from the "Portal" (http://www.frozenmountain.com/portal) on the "Order History" tab

Trial Users: You can grab a copy from the "Downloads" (http://www.frozenmountain.com/websync/downloads)

On-Demand Users: You don't need to do anything, this fix has been applied for you already :)

Happy coding!

Hey everyone!

It's that time again - time to check out the latest version of WebSync! In 3.1, we've got a bunch of new stuff, and a number of other fixes too:

• General
  • Full support for the .NET Compact Framework, version 2.0+ (woohoo!)
  • Updated the core serialization so it can handle incorrect but salvageable JSON inputs
  • Updated examples so that the serialized data is the same between the .NET and JavaScript examples
  • Updated the StatelessProvider API to take a ClientRecord parameter for ConnectClient method implementations for future compatibility

• Server
  • Added a new static method for deserializing incoming message and publications directly from a raw HTTP request (so you can pre-process them if you need)
  • Added a few minor performance improvements

• Clients
  • [.NET] Added a new "OnRequestCreated" event for the .NET client and publisher to allow full control of the web request before it's delivered
  • [.NET] Fixed a bug in the .NET client where the subscription reference would get held after the channel was unsubscribed
  • [JavaScript] Added handling for complete network failures (such as pulling the computer's network jack) to the JavaScript client
  • [All] Fixed a bug in the server that allowed a client that had been disconnected to publish
  • [All] Fixed a bug in the .NET and JavaScript clients with mult-channel subscriptions

As a random side note, the JavaScript client is now very determined to stay connected; we tried just about everything to prevent it from staying online, and it always jumped right back in...

For those of you using WebSync On-Demand, your new URL is: http://sync3.frozenmountain.com/client.js?v=3.1.0

For those of you using WebSync Server, check out our downloads page. If you've already purchased and want the latest, log in to the Portal and check out your "Order History" tab.

Thanks everyone for your feedback, and enjoy!

It's here! On-Demand officially supports SSL.

Using On-Demand SSL is trivial. Just change the script tag to load over https:// (i.e. https://sync3.frozenmountain.com/client.js). As long as your page is SSL-secured, the client will automatically configure itself to encrypt all communications.

Happy coding!

With WebSync Server 3.0.2, we've introduced the targedScan web.config attribute and the WebSyncMethodContainer assembly-level attribute. Together, they can help to reduce memory consumption significantly. This is especially important for shared hosting environments, but is a good practice for any production system.

Before explaining what the new attributes do, let's first look at why memory consumption is an issue at all.

WebSync lets you decorate methods with attributes so they attach to specific server-side events (BeforePublish, AfterSubscribe, etc.). This ability is what makes WebSync so extensible and part of what makes it so easy to use. In order for WebSync to invoke the methods, though, it first has to find them. To do that, WebSync scans the currently loaded assemblies, looking at each type and checking for methods that are decorated with WebSyncEvent or WebSyncScriptModifier. This scan happens just one time, at first run, after which the decorated method information is cached and can be accessed later as needed.

So what's the problem?

Well, there's one small catch. Reflection is expensive, and the .NET framework architects made a design decision a long time ago that any reflective calls for metadata should be cached internally rather than allowing developers to implement caching solutions themselves. This means that whenever type or method information is accessed, the metadata is cached permanently in the application domain. The intention of the architects was to ensure that the reflective work was only every performed once, but for server environments with scarce resources, this is a problem.

As WebSync scans the assemblies/types/methods, .NET caches every piece of information. The internal .NET bloat can be noticeable, even upwards of 100MB memory consumption. We think you would agree, the memory could definitely be put to better use.

Enter the targetedScan and WebSyncMethodContainer attributes, which define where and how to scan.

If targetedScan is set to true in web.config (WebSync/server[targetedScan]), WebSync will ONLY analyze types that are explicitly specified by the WebSyncMethodContainer assembly-level attribute.

For example, if your WebSyncEvent methods are defined in a class called MyWebSyncEvents, simply place the following attribute in AssemblyInfo.cs (in your Properties folder):

[assembly: WebSyncMethodContainer(typeof(MyWebSyncEvents))]

Now, if targetedScan is set to true, WebSync will restrict its scan to just that type and its methods, ignoring all other types/methods and thereby preventing their metadata from being cached by .NET.

(Note: WebSyncMethodContainer can be defined multiple times per assembly, once for each type containing WebSync methods.)

We highly recommend that you use this approach, especially in production systems and reusable extension class libraries. There is no reason to have unnecessary memory consumption, especially when that memory could be used to increase concurrency :)

Well, they just keep coming! We've got a new release ready for you. WebSync On-Demand customers, simply adjust your script files to point to ?v=3.0.2 to take advantage of the fixes and performance improvements. WebSync Server customers, you can grab a new copy from our downloads section, or for those of you who've made a purchase already, you can now easily grab the latest version by simply logging in to the portal and going to the "Order History" tab where you'll find a link to download the latest copy of your particular version of WebSync.

Overall, this release can be summarized as a few performance enhancements (some through a new feature, the "targetedScan" web.config entry) and a few bug fixes. The total list is as follows:

• A new "targetedScan" web.config option for WebSync initialization has been added; using this feature can help reduce initial load time and memory usage, and it's highly recommended for production setups. It's used in conjunction with the new WebSyncMethodContainer attribute, which allows you to specify which assemblies and classes WebSync should analyze.
• Added performance tuning scripts for machines hosting WebSync Server
• Added auto-caching enhancements for the JS client to improve load time, especially under HTML5 postMessage scenarios
• Added domain name sanitization to the PHP publisher so regardless of where the domain name is set, it's cleaned up properly
• Fixed a few bugs - core serialization with un-matched curly or square brackets within a string, reconnect events after a network failure, and a subscribers re-subscribe issue.

Happy coding!

Well, as always, we release a product, and the floodgates are opened :). Thanks everyone for your feedback! We've now released WebSync 3.0.1 (that was quick!).

This release adds a few features, updates the documentation, and fixes a bug or two. Here's the list of changes:

• Added Silverlight components to support the "Subscribers" and "ReturnData" extensions (thanks Santiago!)
• Added an additional example demonstrating the use of the "Subscribers" and "ReturnData" extensions from a .NET environment
• More documentation of use of extensions and how they're created
• Removed a conflicting library reference that was causing problems for VB applications running on .NET > 2.0
• Fixed an issue with event handlers inside partial classes
• Made the "Before" events fire for cascaded events (see below for details on this one)
• The "Community" edition now supports SSL; you asked, we listened :)

There have also been a few minor updates to the online tutorials for WebSync 3 to fix some inconsistencies (thanks Troy!)

Regarding the "Before" events: in all previous versions of WebSync (including WebSync 2), certain events would only trigger an "After" event to fire. For example, when a user disconnected, the "AfterUnsubscribe" would fire, indicating that the users had been disconnected. The reason the "Before" event didn't fire was that these events *cannot* be cancelled. You can set "Successful" to false all you want, but once the user is gone, they're going to be unsubscribed.

As a result, it was possible to write code that you would *think* would work, but wouldn't, such as detecting a "BeforeUnsubscribe" in order to mark a user as unavailable. This has now officially changed.

With WebSync 3.0.1, the "Before" events will fire for *all* actions taken by WebSync, and a flag called "Forced" will be set to true if you cannot prevent whatever action is occurring from continuing. This gives you the information you need to determine if you can prevent the action, and *all* events now follow the same model, firing both a "Before" and "After" for every action that is taken on the server.

This should not be a breaking change, since these events were not firing before, but it is something to be aware of.

Greetings, WebSync Patrons!

Well, we now officially have updated to a new website, and...after many months of hard work...

I'm pleased to announce the release of WebSync version 3.0!

In this release, you'll find:

• Security enhancements in WebSync Server
• Performance improvements
• A new, much more powerful .NET client
• A more powerful, easier to understand WebSync Server API
• Support for custom extensions (keep an eye on our blog for more about this one!)
• A brand new Silverlight client, written in 100% managed code - no more JavaScript bridge!
• Support for the Microsoft Azure platform
• An improved JavaScript client, with more support for HTML5 and even better cross-browser capabilities
• Way, way more documentation!

...and much more! Keep an eye out on our blog for further updates and information, and as always, feel free to drop us a line via our Google Group if you have questions, thoughts, or just want to chat.

For those of you considering upgrading from WebSync version 2, you can check out our migration guide which should help you make the transition smoothly. Don't worry though, we're still supporting you guys too!

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