WebSync 3.0.1 Released (That was Quick!)

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.